[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schemas: Best Practices

  • From: "Roger L. Costello" <costello@m...>
  • To: xml-dev@l...
  • Date: Mon, 08 Jan 2001 08:07:10 -0500

schema advantages
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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.