Altova Mailing List Archives

Re: [xml-dev] Errors in Kendall Clark's article on QNames

From: amyzing@--------.--- (--- ----- )
To: Tim Bray <tbray@----------.--->, xml-dev@-----.---.---
Date: 2/13/2002 8:44:00 PM
On Wed, Feb 13, 2002 at 09:56:32AM -0800, Tim Bray wrote:
>At 01:50 PM 13/02/02 +0000, Henry S. Thompson wrote:
>I fought against letting QNames escape into content, lost 
>the argument to James Clark, but I'm beginning to think that
>the cost-benefit trade-off is positive, despite the considerable

Could you expand on this, please?

I've become convinced that the value-space and the markup-space ought
not overlap.  That is, each individual application of XML that happens
to need QName-typed or QName-type-including-typed element and attribute
values ought to have a separate, application-specific mechanism for
declaring those namespaces.  For instance, XSLT would define separate
namespace bindings for the transformation document itself, for the
input document, and for the output document.  It sounds as though you
don't think such partitioning could be useful, so I wonder if you would
explain why you think the mixture is positive?

>>2) "..there's no way for an XML processor to tell whether QNames are
>>   used in values." (again, quoting Lenz [2], ellipses in original)
>>That's simply false -- any sensible use of QNames would involve a W3C
>>XML Schema or other type-assigning schema language, 
>No, Henry.  A substtantial proportion of application use no schemas
>whatsoever past design time.  Yes, IF you have a schema language
>that supports QNames as a type and IF you have a such a schema for
>the XML language you're using and IF you're willing to take
>the overhead of schema validation at run-time, THEN there
>is a way for an XML processor to tell whether QNames are 
>hiding in content.  Otherwise not. -Tim

Note that the problem is not just QNames, and in fact if QName were not
already a defined datatype in XSDL, it would be trivial to add it.

Try defining the pattern for an XPath expression, though.  Especially
considering that the pattern facet doesn't allow the shorthand of
referring to existing types as part of the pattern (unless I'm missing
something).  If you don't have an XPath type, and give up on creating
one, then the type of elements and attributes that contain XPaths is
probably going to be "string".  Schema provides BNF for a subset of
XPath expressions, but even using the BNF, the expansion into a pattern
facet is painful (and ugly).  As a result, the PSVI probably won't
indicate that an item has XPath type, meaning that all those QNames are

I rather suspect that other problems exist as well, when even in the
presence of a schema, with validation turned on, certain information
items are insufficiently strongly typed to be identified as containing
QNames.  This is primarily a problem because it crosses boundaries; the
application normally doesn't expect to have to maintain a stack for
namespaces--the parser does that.  When attributes or elements contain
structural (even, arguably, lexical) constructs, then the application
needs access to the internal state of the parser.  I think this is not

Amelia A. Lewis          alicorn@m...          amyzing@t...
Never imagine yourself not to be otherwise than what it might appear to others
that what you were or might have been was not otherwise than what you had been
would have appeared to them to be otherwise.                    -- The Duchess


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.