Re: [xml-dev] Portable Constraints

[Stephen D Green <stephengreenubl@gmail.com>]

Just to put in my vote in favour of Roger's suggestion, though.
I kept quiet because I do rather frequently pipe in to Roger's
postings and thought I'd stand back a bit; but I really do think
Roger hit on a very important point - that although the design
of XML Schema 1.1 allows for portable assertion constraints
it also allows constraints to be added which by nature reduce
portability. This does have to be bourne in mind when using
assertions to supplement a schema, I agree. I have come
across very significant scenarios of usage of assertions where
portability via what is termed "atomicity" is a major design
requirement and here it may be important to restrict the way
assertions are written such that portability is maintained. If
your scenario does not have this requirement then you might
make use of the ability to wrap an assertion around a group
of elements and their descendants but if you do you might
remember that this has a side-effect of creating a grouping
of those descendants which, by reducing their atomicity,
makes it so they can only be reused as a group and not split
into reusable subcomponents. You have take a risk that this
could hinder present and future portability of any of the
descendants.

----
Stephen D Green



On 2 April 2011 09:12, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
> 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
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>