Re: [xml-dev] Portable Constraints

[Mukul Gandhi <gandhi.mukul@gmail.com>]

Hi Roger,
    To my opinion, the idea of portable schema constraints is useful.
But in the example you've shown the "Publisher" element seems to be
too granular for implementing this concept and that is probably
causing no takers of this idea.

Moreover writing the "storename" attribute on Publisher seems to
create a data model, that is not in sync with the problem domain (in
an ideal situation, I believe attribute "storename" must be on
BookStore for stakeholders of the problem design to readily accept the
data model).

Non responsiveness from community so far probably indicates, that the
design problem proposed in this thread is not a significant concern in
XML Schema design.

Probably if we can have a different and a better example, to identify
portable schema constraints then I think many of us could find this
pattern quickly useful.

On Thu, Mar 31, 2011 at 4:50 AM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Folks,
>
> [Definition] Portable Constraints: the ability to take an element declaration, with all its constraints, out of one XML Schema and drop it into another XML Schema, with all its constraints intact.
>
> Example: The value of Publisher depends on which book store it is contained within:
>
> --------------------------------------------------
> <?xml version="1.0"?>
> <BookStore storename="Barnes and Noble">
>        <Book>
>                <Title>Don't Make Me Think</Title>
>                <Author>Steve Krug</Author>
>                <Date>2006</Date>
>                <ISBN>0-321-34475-8</ISBN>
>                <Publisher>New Riders</Publisher>
>        </Book>
>        ...
> </BookStore>
> --------------------------------------------------
>
> If the store is Barnes and Noble then valid Publishers are Wrox Press and New Riders.
>
> If the store is Borders then valid Publishers are Norton Press and friendsofed.
>
> Earlier we examined two approaches to expressing the constraint on Publisher:
>
> 1.  Position an <assert> element on the BookStore element declaration:
>
>   Assert: Book/Publisher = ('Wrox Press', 'New Riders')
>
> 2. Position <alternative> elements in the Publisher element declaration:
>
>   Alternative: if @storename='Barnes and Noble' then
>                    text() = ('Wrox Press', 'New Riders')
>   Alternative: if @storename='Borders' then
>                    text() = ('Norton Press', 'friendsofed')
>
> and on the root element declare a storename attribute "inheritable."
>
> The disadvantage of both solutions is that Publisher is not portable. The first approach requires an ancestor element impose the constraint on Publisher. The second approach requires an ancestor element have an inheritable storename attribute. That "contextual stuff" will be lost when Publisher is moved to other XML Schemas.
>
> How can we design Publisher to be portable?
>
> Portability approach: add a storename attribute directly on Publisher:
>
> <Publisher storename="Barnes and Noble">New Riders</Publisher>
>
> The XML Schema declares the Publisher element like this:
>
> ----------------------------------------------------------------------
> <xs:element name="Publisher">
>    <xs:complexType>
>        <xs:simpleContent>
>             <xs:extension base="xs:string">
>                <xs:attribute name="storename" type="xs:string" />
>                <xs:assert test="if (@storename = 'Barnes and Noble') then
>                                     text() = ('Wrox Press', 'New Riders')
>                                 else if (@storename = 'Borders') then
>                                     text() = ('friendsofed', 'Norton Press')
>                                 else false()"/>
>            </xs:extension>
>        </xs:simpleContent>
>    </xs:complexType>
> </xs:element>
> ----------------------------------------------------------------------
>
> Now the Publisher element is portable: all its constraints are positioned within its element declaration; the element declaration can be copied and dropped into other XML Schemas without dragging around a bunch of "contextual stuff."
>
> What are your thoughts on this approach to designing portable elements?
>
> Is portability important? What other techniques can be used to facilitate portability?
>
> /Roger




-- 
Regards,
Mukul Gandhi