[
Lists Home |
Date Index |
Thread Index
]
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
>cost.
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
overlooked.
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
good.
Amy!
--
Amelia A. Lewis alicorn@mindspring.com amyzing@talsever.com
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
|
