[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML Schemas: Best Practices
- From: "Roger L. Costello" <costello@mitre.org>
- To: xml-dev@lists.xml.org
- Date: Mon, 08 Jan 2001 04:28:03 -0500
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