OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XML Schemas: Best Practices



Curt Arnold wrote:
> 
> The choice construct requires you to explicitly change the definition
> of the containing element which may be in a schema you do not 
> control. Substitution groups allow you to implicitly change the
> containing element at the definition of the contained element.

Wow! A few words with a lot of implications. This is really awesome!

I have spent a considerable amount of time thinking about the above
words. Below is a summary of what I have come to learn.
Please let me know if I have not understood all implications.

Implications of Method 1 versus Method 2 in terms of extensibility
of a variable content container element:

Recall Method 1 - it uses an abstract element and substitutionGroup
to implement a container element with variable content.

With Method 1 you can extend the set of elements that may be 
used in the variable content section, even if the schema is outside 
your control. For example, suppose that you do not have privilege 
to modify the Catalogue schema. Currently, the Catalogue 
schema only supports Book and Magazine elements in the variable 
content section. But your instance documents also need CD elements: 

   <Catalogue>
        <Book> ... </Book>
        <CD> ... </CD>
        <Magazine> ... </Magazine>
        <Book> ... </Book>
   </Catalogue>

How can you extend the Catalogue schema, without modifying it?

You can create your own independent schema which contains a 
declaration for CD that extends the PublicationType defined in the 
Catalogue schema, and joins the Publication substitutionGroup: 

    <import namespace="http://www.catalogue.org"
            schemaLocation="Catalogue.xsd"/>
    <complexType name="CDType">
        <complexContent>
            <extension base="c:PublicationType" >
                <sequence>
                    <element name="RecordingCompany" type="string"/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>
    <element name="CD" substitutionGroup="c:Publication" 
             type="cd:CDType"/>

The CD element meets the requirements for being in Catalogue's variable 
content section - its type derives from the PublicationType, and 
it is a member of the Publication substitutionGroup. Thus, instance 
documents may now use Book, Magazine, or CD in the variable content 
section - provided, of course, instance documents specify this new 
CD schema as well as the Catalogue schema in its schemaLocation: 

    xsi:schemaLocation = "http://www.catalogue.org
                          Catalogue.xsd
                          http://www.cd.org
                          CD.xsd"

Thus, we see that this method (Method 1) allows us to extend the 
Catalogue schema, without modifying it. Wow!

Now consider Method 2 - use a repeatable <choice> element to implement
a container element with variable content.

Again, suppose that the Catalogue schema is outside your control. 
Currently the variable content section only supports Book and Magazine. 
Your instance documents needs CD as well as Book and Magazine, e.g., 

    <Catalogue>
        <Book> ... </Book>
        <CD> ... </CD>
        <Magazine> ... </Magazine>
        <Book> ... </Book>
    </Catalogue>

This method requires that the element in the Catalogue schema be 
modified to include the CD element. However, the Catalogue schema 
may be outside your control, so you may not be able to get it 
extended to include the CD element. Thus, this method has serious 
restrictions on its extensibility. 

This is so cool!  /Roger