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 10:35:40 -0600
Message-ID: <4242EC5C.50400@innodata-isogen.com>
To: xml-schema-dev <xmlschema-dev@w3.org>

Eliot Kimber wrote:
> 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. 

I think the key difference, now that I think more about it is that for 
HyTime and DITA-style archtictures, the validity of the specialized 
result is checked for *instances* while for XSD it is checked for types. 
This is roughly the difference between having a compile-time or a 
run-time failure to conform to an API.

In HyTime Architectures, the driving philosophy was that what mattered 
was instances and that we didn't want to constrain local document types 
from allowing instances that did not conform to the architecture (for 
example, to allow a mixture of non-conforming legacy instances and 
conforming new instances).

DITA is a little more dogmatic, defining some rules that specialized 
DTDs have to conform to, but I submit that those rules are largely 
unenforcable and, to my mind, pointless except as an aid to implementors 
to check their work (sort of like the difference between weekly and 
strongly typed languages). But in any case, what matters at the end of 
the day is whether or not a given document instance conforms or doesn't 
to a particular architectural type.

By contrast, XSD is defining rules for validating type declarations, 
which is an inherently more difficult task and requires the imposition 
of more constraints in order to make it practical.

I will note that when we were designing the HyTime architecture 
mechanism we explicitly recognized that the validation of specialized 
content models against architectural models was at best difficult and at 
worst impossible in the general case (and that we didn't have the time 
or ability to prove mathematically what the actual case was), which was 
another reason we chose to limit architectural validation to instances. 
We also recognized that for most practical applications, inspection of 
specialized content models was sufficient to determine whether or not 
the content model would either allow conforming architectural instances 
or allow only conforming instances.

So in that sense, HyTime/DITA and XSD are addressing two different sets 
of requirements for specialization and therefore it's not a complete 
surprise that they aren't completely compatible. But it's still 


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

Received on Thursday, 24 March 2005 16:35:21 UTC

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