John.Hockaday@g... wrote:
> However, and I'm not sure about this, it seems that if one extends a W3C XML
> Schema then one needs to not only identify the new XSD via a namespace but
> one also needs to include the original XSD that has been extended.  If this
> is so then XML document instances can become *very* messy when there is an
> extension of an extension of an extension etc..  

I'm not sure I understand this comment, as XSD schemas are not syntactic 
parts of XML documents (in sharp contrast to DTDs, which *are* syntactic 
parts of XML documents, leading to many of the problems with them 
experienced over the years).

That is, any messiness will be in the extending schema itself, which 
handles any importing and extending of the base namespace's schema. But 
this has no (direct) effect on instances, which simply point to the 
extending schema.

This points to one of the key differences between schemas like XSD 
schemas and DTDs: schemas are *not* syntactic components of the 
documents they govern. This removes any direct *syntactic* dependencies 
between instances and schemas and also removes the ability for document 
authors to unilaterally (and in a conforming DTD-validating XML 
processor, undetectably) subverting the validation process (and possibly 
the processors that consuming the validated documents) by changing the 
DTD declarations. Authors can do this with DTDs. They cannot do it with 
schemas.

The most authors can potentially do with schemas is change the 
schemaLocation hint, but any system that depends on the application of 
the correct schema to documents will ignore schemaLocation use an 
application-controlled namespace-to-schema binding mechanism, which 
cannot be subverted by authors through changes in the instances. This is 
key. No *conforming* DTD-based XML processor can provide this level of 
control, for the simple reason that the syntactic processing DTDs is not 
optional for validating XML processors. Any system that, for example, 
requires that documents no have internal DTD subsets *is not conforming*.

Cheers,

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

ekimber@i...
www.innodata-isogen.com


From John.Hockaday@g... Tue May 10 07:12:49 2005
Received: from maggie.w3.org ([193.