Re: XML Schemas: Best Practices

["Roger L. Costello" <costello@mitre.org>]

Hi Folks,

I think that I now see an advantage of method 3 (a big advantage). 
Recall that this method uses type substitution and results in instance 
documents that look like this:

    <Catalogue>
        <Publication xsi:type="BookType"> ... </Publication>
        <Publication xsi:type="MagazineType"> ... </Publication>
        <Publication xsi:type="BookType"> ... </Publication>
    </Catalogue>

Catalogue is a "variable content container element" by virtue of the
fact that the content of the Publication elements can vary.

The advantage that I see of Method 3 is with regards to extensibility.
I now believe that Method 3 is the most extensible method.

With method 3 the only requirement for participating in a variable 
content container is to create a type which derives from the 
abstract type.  For example, anywhere PublicationType is used then
any type that derives from it may type substitute for it.  If 
PublicationType is publicly available then many schemas may
derive from its definition, resulting in potentially massive 
extensibility.  For example, if a schema author creates a type, CDType,
which extends the publicly accessible PublicationType:

    <complexType name="CDType">
        <complexContent>
            <extension base="c:PublicationType" >
                <sequence>
                    <element name="RecordingCompany" type="string"/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>

then in an instance document I can use the new CD type:

    <Catalogue>
        <Publication xsi:type="BookType"> ... </Publication>
        <Publication xsi:type="CDType"> ... </Publication>
        <Publication xsi:type="MagazineType"> ... </Publication>
        <Publication xsi:type="BookType"> ... </Publication>
    </Catalogue>

On the other hand, with Method 1 there are two requirements for 
participating in the variable content container:

1. You must create an element which is in the substitutionGroup with
   the abstract element.  For example, create a CD element and put it
   in the substitutionGroup with Publication.

2. The type of the element that you create must be the same as, or
   derived from the type of the abstract element.  For example,
   CDType derives from PublicationType.

I am starting to think of element declarations as being components 
that will typically be non-public and used to solve a narrow problem, 
whereas type definitions will typically be public and general purpose. 

For example, I would envision that PublicationType would be put into 
a publicly accessible schema, whereas the Publication element would be 
put in a non-public, private Catalogue schema. 

If this vision is correct, then it argues for using Method 3 because
only the types are publicly accessible and not the elements.  For 
example, PublicationType is publicly available, whereas the 
Publication element is not.  To achieve extensibility, Method 1 relies 
on both the Publication element and PublicationType being publicly
accessible, whereas Method 3 only relies on PublicationType being 
publicly accessible.

Question: How do you envision dealing with types and elements - do you
see types as typically being put in publicly accessible schemas,
whereas elements declarations being kept in private schemas?

Lastly, while I am starting to think that method 3 may have some
real advantages over method 1, I really despise instance documents
that look like this:

    <Catalogue>
        <Publication xsi:type="BookType"> ... </Publication>
        <Publication xsi:type="MagazineType"> ... </Publication>
        <Publication xsi:type="BookType"> ... </Publication>
    </Catalogue>

I much prefer to see instance documents looking like this:

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

I can't put my finger on why I like the later better, other than
to say that I find it "cleaner".  Of course, that is a totally
subjective statement, and hence irrelevant.  Any thoughts?  /Roger