- From: Eliot Kimber <ekimber@innodata-isogen.com>
- Date: Thu, 24 Mar 2005 09:56:00 -0600
- 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.... Cheers, Eliot -- W. Eliot Kimber Professional Services Innodata Isogen 9390 Research Blvd, #410 Austin, TX 78759 (512) 372-8155 ekimber@innodata-isogen.com www.innodata-isogen.com
Received on Thursday, 24 March 2005 15:55:16 UTC