Re: Potential new issue: PSVI considered harmful

I see several different problems with the PSVI.

(a) It makes documents less self-contained.

(b) Applications that depend on a PSVI now require a very complex, 
heavy-weight schema validation process, rather than a relatively simple 
parsing process.

(c) Applications that depends on a PSVI must agree not only on the choice 
of schema language but also on the choice of mechanism to locate the 
schema. As has been pointed out, xsi:schemaLocation is just hint; there is 
no single way that is mandated for an application to locate a schema. XML 
Schema does not specify a single way to get from a URI specifying a 
document to a PSVI; it only specifies the way to get to a PSVI from a URI 
specifying a document together with a mapping from namespace URIs to schema 

(d) The PSVI is not XML; this is the most insidious problem. With something 
like default values, you can perform a normalization process and produce a 
self-contained document where defaults are explicit. The declaration of 
default values defines a mapping from an XML infoset to another instance of 
an XML infoset. It is not necessary to add complexity to applications to 
deal with default values. However, the W3C XML Schema PSVI is not like 
this; a PSVI is not an XML infoset. You cannot perform the PSVI infoset 
augmentation as a separate XML to XML transformation. All applications 
dealing with the PSVI are dealing with a different, more complex structure 
than applications that deal with pure XML. Applications communicating with 
the PSVI become much more tightly coupled: when applications communicate 
using the XML infoset, they do not have to share an address space, because 
there is a standard serialization of an XML infoset as XML, but this does 
not apply with the PSVI.  I believe this is a catastrophic architectural 
mistake in XML Schema, and it needn't have been like this: schema infoset 
augmentation could and should be defined as an XML to XML transformation 


Received on Monday, 17 June 2002 02:47:50 UTC