Re: XML Schemas: Best Practices

[Martin Bryan <mtbryan@sgml.u-net.com>]

I've been using Abstract Elements in two contexts. In both cases I decided
against using abstract typing. Let me try to document why to see if a) I had
valid reasons b) it helps resolve the Best Practice debate.

The first application I applies the abstract concept to was an XML Schema
for ISO 13250 Topic Maps (http://www.diffuse.org/TopicMaps/schema.html).
What I was seeking to do here was to show that the Schema was a template for
the generation of working instances of topic maps schemas, and not intended
to be used as a working schema in its own right. However, I did want to make
it easy for people to import the type definitions into their working
Schemas, and so decided that making the types abstract types would not help
in the process of reusing the type definitions. I therefore decided that a
combination on non-abstract type definitions plus abstract element
definitions that could be used as the basis for substitution groups wherever
there were advantages in aggregating the processing of certain elements was
the best way to go.

The second application I am using them on is the metamodel for core
components in ebXML. Again the whole idea of these core components is to
provide templates that can be used to build significant parts of a working
schema. The models defined for core components are unlikely to be used
without some form of qualification. In some cases only a subset of the
contents will be required, in others additional components will be needed
for certain conditions. There will be cases where both restriction and
extension apply to the same core component. There will also be cases where
all that needs to be modified are properties such as minOccur and maxOccur,
or the datatyping associated with an element.

In this second application there is a distinct need to keep the final
message as compact as possible, and to rely on schema properties to control
the processing of the document. If you are relying on schemas to provide
information about things like datatyping, then you can also rely on them
providing information on the type from which the model was derived. In this
case we are again trying to get people away from the slavish use of a single
element name to represent a class. For example, rather than having Person as
the class, we want to see the element name reflect the role the person is
playing in the message scenario (e.g. Buyer or Seller). Different roles
normally require different processing, but shared datatypes normally
indicate a shared data storage model. In our case both of these occur. For
event-based processing we need role-based element names. For storage and
retrieval we need to be able to identify the type the element is derived
from.

Now the question comes as to whether XSLT is event-based or storage-based,
and whether XPath is a storage-based model or an event-based one. Here I
have to admit I am on dodgy ground. I see element names as being a better
control mechanism in XPath statements and XSLT select/match definitions.
However, I would like to be able to have processes that depend on the
substitution group an element belongs to. I think this is what I will get
from using substitution groups once XPath and XSLT get updated to provide
access to the substitution group data that DOM3 will need to be providing
access to. Maybe I'm looking too far into the future here, but I cannot see
how we can survive long without substitution groups being referencable. In
the meantime we will need to rely on the unique names assigned to each
member of the substitution group.

Martin Bryan