W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2005

Re: [Bulk] Trying to Understand Complex Abstract Types: How ToDefine?

From: Eliot Kimber <ekimber@innodata-isogen.com>
Date: Thu, 24 Mar 2005 09:56:00 -0600
Message-ID: <4242E310.9060703@innodata-isogen.com>
To: xml-schema-dev <xmlschema-dev@w3.org>

Henry S. Thompson wrote:
> I'm afraid your example/discussion depends on knowledge of a schema
> (DITA?) which I'm not familiar with.

It's not a function of the schema, but of the desire to use a particular 
pattern of specialization typified by the HyTime SGML Architecture 
mechanism in ISO/IEC 10744:1996 and the "class" mechanism in DITA (which 
can be viewed as a simplification and refinement of the HyTime 
mechanism). This specialization approach can be applied to any document 
type and is independent of the details of the schema (but its use is 
most obvious in the context of the DITA specification, which is 
expressly defined as a base for specialization).

In both of these cases, you define "architectural types" that define the 
  required content and attribute patterns that specializations must 
conform to. However, the specializations allowed are more flexible than 
in XSD. In particular:

- If the supertype content model allows A+ then any combination of 
elements derived from A, in any order, is allowed in specialized content 
models. In XSD if the supertype content model is A+ then all you can do 
in a restriction substitution group is have *exactly one* particle whose 
type is A. This is a serious restriction.

- If the supertype content model allows (A | B) then specializations may 
allow elements specialized from just A, just B, or A and B, in either 
order. XSD requires that the order of particles be preserved, even when 
the base content model allows either order.

Thus it's not an issue that XSD disallows the use of substitution groups 
but that the limitations on the restriction feature of XSD make 
substitution groups unusable as a way to express the specialization 
semantics of DITA- and HyTime-style architectures.

This is frustrating because a weakness of these architectural mechanisms 
it that, for all intents and purposes, they are extra-schema mechanisms 
that must be implemented at the instance processing level, not at the 
info set construction/validation level. This puts extra burdens on 
implementors of systems that need to support these types of specializations.

I would submit that almost all technical documentation applications need 
this type of specialization mechanism.

XSD is a powerful mechanism and provides many useful facilities, so it's 
all the more frustrating when it doesn't quite meet a key requirement.

So it goes.

There's always the next revision of the spec....


W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8155

Received on Thursday, 24 March 2005 15:55:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:07 UTC