Re: XML Schemas: Best Practices

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

Hi Folks,

I never would have imagined this issue to have so many twists and
turns.  Initially, I thought that method 2 (repeatable <choice> element)
was the superior method. Then I switched to method 1 (abstract element
and element substitution) as the favorite method.  Now I have become
convinced that method 3 (abstract type and type substitution) is the
best.

Here are my reasons for thinking that Method 3 is the best.

1. Extensibility: the contents of the variable content container
   may be extended by other schemas simply by creating a new type
   which derives from the abstract type.  Thus, the variable content
   container may be extended, without any modification to its schema!
   (see yesterday's message for a complete discussion of this)

2. Minimal Dependencies: the only requirement for extending the
   variable content container is to have access to the abstract
   type (contrast with Method 1 which requires access to both
   the type and the abstract element).  (again, see yesterday's 
   message for a complete discussion of this)

3. Consistent Processing: since each element in the variable content
   container is the same (e.g., Publication) it will be easy to 
   process.

   Example.  Consider this variable content container:

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

   A stylesheet could process each Publication element as follows: 

     <xsl:for-each select="Publication">
        -- do something --
     </xsl:for-each>

  Contrast that with what would be required for a collection of 
  differently named elements, where we would need to special case
  each element: 

     <xsl:if test="Book">
        -- process Book --
     </xsl:if>
     <xsl:if test="Magazine">
        -- process Magazine --
     </xsl:if>

  Of course, this later stylesheet also suffers from lack of 
  scalability, i.e., it breaks as soon as a new element is added

4. Semantic Cohesion: the content of the variable content container
   all descends from the same type hierarchy.  This enables type 
   checking of the variable content container. (see Len's message from
   last week for a complete discussion of this)

To be fair, I should list the disadvantages:

1. No Independent Elements: all types must descend from the abstract 
   type. This requirement prohibits the use of types which do not 
   descend from the abstract type, as would typically be the situation 
   when the type is in another, independently developed schema. 

Note that Method 1 also has this limitation.  Method 2 has a serious
extensibility limitation.  Thus, overall I think that this method has
the greatest benefits.  Unless otherwise persuaded, I will recommend
using Method 3 as Best Practice.  

Thanks again to Curt, Len, Rick, and Jeff for all their inputs on this
issue!

/Roger