OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] A plea for Sanity

[ Lists Home | Date Index | Thread Index ]

On Friday, April 5, 2002, at 11:05  PM, Eric van der Vlist wrote:
> What about declaring those documents?
> <?sanity type="normal|sane|neurotic|psychotic"?>
> with a default value of psychotic (unfortunately, but you can't assume 
> documents to be normal nor even sane) would allow consumers to adapt 
> their behavior or even to reject documents they don't like...

I'd prefer a simpler boolean choice between preserving the [in-scope 
namespaces] property and simply throwing that information away:

   <?xmlns preserve="yes|no"?>

with a default value of "yes" (for backward compatibility with XSLT, XSD, 
SOAP, etc.).

It side-steps the sanity vs. insanity issue by introducing the possibility 
of a namespace-infoitem-less infoset instance. When preserve="no", the 
namespace environment, sane or not, can be chucked, because all that 
matters is that every element and attribute name consists of a {URI, 
local-name} pair. I'm not sure whether that option would help Joe's, er, 
XML's, mental health. I suspect that it would. It also seems like a much 
easier thing to require on an application-specific basis, whereas 
disallowing "psychosis" strikes me as similar to SOAP's rumored 
disallowance of DTDs, mentioned a while back on that "civil disobedience" 
thread, i.e. allowing application-specific validation constraints to hook 
a little deeper than is comfortable for many of us (leaving us with the 
suspicion that they're getting away with using something other than an XML 
parser(!)). The difference with <?xmlns preserve="no"?> is that it's 1) 
new (no established practice) and 2) trivial to identify (by humans and 
machines alike). It could even -gulp- be added as a constraint in the next 
version of W3C XML Schemas.

The remaining piece of the puzzle is QNames in content. Those of us who 
question the sanity of the decision to use the namespace environment to 
resolve QNames in content in the first place--we can use application-level 
declaration mechanisms to resolve QNames in content (probably making them 
global to the document so as not to reinvent the problems of XML 
Namespaces). And we'll be none the poorer for dispensing with the beloved 
namespace environment, whatever its psychological condition.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS