xml-dev - Re: XML Schemas: Best Practices

[Eric van der Vlist <vdv@dyomedea.com>]

One thing to consider in the choice between these paradigm is wether the
components will be referenced from elsewhere (schemas describing other
namespaces or instance documents) or even from the schema itself...

The XML Schema primer [1] is somewhat fuzzy when mentioning the scope of
references:

"In general, the value of the ref attribute must reference a global
element, i.e. one that has been declared under schema rather than as
part of a complex type definition." 

(if it's in general, what are the exceptions :) ??)

But the part [2] states that:

"Reference to schema components from a schema document is managed in a
uniform way, whether the component corresponds to an element information
item from the same schema document or is imported (References to schema
components across namespaces (§6.2.3)) from an external schema (which
may, but need not, correspond to an actual schema document)."

possibly meaning that even local references to non global schema
components is forbidden.

Along the same lines, I find it interesting to see that groups (even
single element groups) can be used to differentiate elements with the
same name but different structure and or type.

For instance:

<xsd:group name="eltInContext1">
 <xsd:sequence>
  <xsd:element name="elt" type="xsd:string"/>
 </xsd:sequence>
</xsd:group>

<xsd:group name="eltInContext2">
 <xsd:sequence>
  <xsd:element name="elt" type="xsd:integer" maxOccurs="unbounded"/>
 </xsd:sequence>
</xsd:group>

Generally, a group can be used in place of an element (a notable
exception being xsd:all) and these 2 groups defined globally can be
referenced to differentiate these 2 instances to the element.

Eric  

[1] http://www.w3.org/TR/xmlschema-0/#DefnDeclars
[2]
http://www.w3.org/TR/2000/WD-xmlschema-1-20000922/#refSchemaConstructs

Jon Cleaver wrote:
> 
> Roger, All,
> 
> Names for the two design paradigms: Componentized vs. Heirarchical?
> 
> 1. The Componentized approach
> 
> This makes global definitions of elements and types, then combines
> these in an arbitrary manner locally. This makes the first level of
> the schemas more complicated but this is offset by greater simplicity
> deeper into the schema where components can be reused.
> 
> The trade-off with this approach is that it means that any change to
> one of the components can propagate throughout the schema, or other
> schemas that the component. This necessitates the identification of
> dependancies and how they might be affected by any structural change.
> 
> 2. The Heirarchical approach
> 
> This defines all components and structure locally. As such, the first
> order level of the schema is simpler but deeper down there may be
> additional complexity, due to having to redefine components whenever
> they are used.
> 
> The advantage of this is that any changes to structure will only have
> an impact within the scope of the parent element of the component
> being changed. As such, rigorous dependancy checking is not required
> outside of the sub-system being modified, since it is not visible
> outside of its scope.
> 
> --
> 
> As such, I would suggest that should a sub-component be liable to
> change then I would be inclined to use the second approach, because
> the administration overhead of managing change could become
> prohibitive. Should it be fixed, it may be part of a standard or
> specification, then it should be declared globally as the
> administration cost will be negligible compared to the benefits of
> allowing it to be reused elsewhere.
> 
> Hope this helps!
> 
> Jonathan
> 
> --- In xml-dev@egroups.com, "Roger L. Costello" <costello@m...> wrote:
> > Hi Folks,
> >
> > I would like to move on to the next schema design issue:
> >
> > Issue: When should an element or type be declared global versus when
> > should it be declared local?
> >
> > [Recall that a component (element, complexType, or simpleType) is
> > "global" if it is an immediate child of <schema>, whereas it
> is "local"
> > if it is not an immediate child of <schema>, i.e., it is nested
> within
> > another component.]
> >
> > If someone were to ask you, "In general, when should an element or
> type
> > be declared global versus when should it be declared local?", what
> > advice would you give them?
> >
> > A month ago I would have answered, "as a general rule, make things
> > global".  However, after the discussions that we have had, I would
> have
> > a very different answer today.
> >
> > Example.  Below is a snippet of an instance document.  Let's
> explore the
> > different design strategies for defining <Book> and its components.
> >
> >     <Book>
> >         <Title>Illusions</Title>
> >         <Author>Richard Bach</Author>
> >     </Book>
> >
> > One design approach is to mirror the instance document - declare a
> Book
> > element and within it declare a Title element followed by an Author
> > element:
> >
> > First Design:
> >
> >     <element name="Book">
> >         <complexType>
> >             <sequence>
> >                 <element name="Title" type="string"
> >                          minOccurs="1" maxOccurs="1"/>
> >                 <element name="Author" type="string"
> >                          minOccurs="1" maxOccurs="1"/> />
> >             </sequence>
> >         </complexType>
> >     </element>
> >
> > That's one end of the design spectrum.  At the other end of the
> design
> > spectrum: we disassemble the above instance document into its
> individual
> > components, define each component, and then assemble them together:
> >
> > Second Design:
> >
> >     <element name="Title" type="string"/>
> >
> >     <element name="Author" type="string"/>
> >
> >     <complexType name="Publication">
> >         <sequence>
> >             <element ref="cat:Title"
> >                      minOccurs="1" maxOccurs="1"/>
> >             <element ref="cat:Author"
> >                      minOccurs="1" maxOccurs="1"/>
> >         </sequence>
> >     </complexType>
> >
> >     <element name="Book" type="cat:Publication"/>
> >
> > These approaches represent both ends of the design spectrum.
> >
> > For this issue, I like to think in terms of boxes, where a
> represents an
> > element or type.  Thus,
> >
> > - The first design approach corresponds to having a single box, and
> it
> > has nested within it boxes, which in turn have boxes nested within
> them,
> > and so on.
> > - The second design approach corresponds to having many separate
> boxes
> > which are composed together.  The composition of the boxes creates
> the
> > whole.
> >
> > I believe that it will be useful to create a name for the two design
> > approaches:
> >
> > - What name would you give to the design strategy where the
> components
> > (i.e., element declarations and type definitions) are nested within
> each
> > other?  It is the "xxxxx" design approach for schema construction.
> > - What name would you give to the design strategy where components
> are
> > defined individually and then composed together?  It is the "yyyyy"
> > design approach for schema construction.
> >
> > Let's examine the characteristics of each of the two design
> approaches.
> > (Perhaps the characteristics will yield insights into appropriate
> names
> > for the two design approaches?)
> >
> > First Design Characteristics:
> >
> > [1] Opaque content. The content of Book is opaque to other schemas,
> and
> > to other parts of the same schema. The impact of this is that none
> of
> > the types or elements within Book are reusable.
> >
> > [2] Localized scope. The region of the schema where the Title and
> Author
> > element declarations are applicable is localized to within the Book
> > element.  The impact of this is that if the schema has set
> > elementFormDefault="unqualified" then the namespaces of Title and
> Author
> > are hidden (localized) within the schema.
> >
> > [3] Compact.  Everything is bundled together into a tidy, single
> unit.
> >
> > Second Design Characteristics:
> >
> > [1] Transparent content. The components which make up Book are
> visible
> > to other schemas, and to other parts of the same schema.  The
> impact of
> > this is that the types and elements within Book are reusable.
> >
> > [2] Global scope. All components have global scope.  The impact of
> this
> > is that, irrespective of the value of elementFormDefault, the
> namespaces
> > of Title and Author will be exposed in instance documents
> >
> > [3] Verbose. Everything is laid out and clearly visible.
> >
> > I am sure that there are other characteristics that I am missing.
> Can
> > you please help to list them?
> >
> > As I see it, the major tradeoff between the two design approaches
> is
> >
> > - The first design approach facilitates hiding (localizing)
> namespace
> > complexities
> > - The second design approach facilitates component reuse.
> >
> > (I find it interesting that this issue is relating back to the
> issue we
> > discussed earlier on when to hide (localize) namespace complexities
> > within the schema versus when to expose the namespaces in instance
> > documents.)
> >
> > Here's a summary of things to be resolved for this issue:
> >
> > (1) What name do we give to (what I have been calling) First Design?
> > (2) What name do we give to (what I have been calling) Second
> Design?
> > (3) What are the other characteristics of the two design approaches?
> > (4) What do you see as the main tradeoffs in the two design
> approaches?
> >
> > Thanks!  /Roger
> 
> --
> Programming today is a race between software engineers striving
> to build bigger and better idiot-proof programs, and the Universe
> trying to produce bigger and better idiots.  So far, the Universe is
> winning.

-- 
------------------------------------------------------------------------
Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
------------------------------------------------------------------------