[
Lists Home |
Date Index |
Thread Index
]
On Wed, 2002-02-13 at 08:50, Henry S. Thompson wrote:
> 1) "Consequently, all scope information, i.e. exactly where every
> xmlns declaration is and what prefix it uses, must always be passed
> to the application, regardless of whether it's needed or not..."
> (quoting Evan Lenz [2], ellipses in original)
>
> This is wrong on two counts. The Infoset REC clearly defines what
> _is_ required for applications that need it, namely the [in-scope
> namespaces] property, which is much simpler than "where every xmlns
> declaration is and what prefix it uses".
That "feature" was added to the Infoset precisely because QNames were
receiving use in attribute values at the W3C. Is it simpler? In some
ways. Does it mean keeping extra scope information around? Definitely.
It still qualifies as a burden to application developers.
> Furthermore, and more to
> the general layering and modularity point at issue, the Infoset REC is
> designed specifically to provide applications with a vocabulary for
> stating what they require from a parser. If an application doesn't
> use QNames in values, it can define its profile of required Infoset
> items and properties to not include the [in-scope namespaces] property
> and the *Namespace* information item. Such applications would then be
> happy with parsers which don't provide this information.
That's completely useless to those of us writing generic XML processing
tools. I get to do a lot of extra work to support your (bogus, IMHO)
use of QNames because my application may well feed into other
applications.
There's no easy escape from that requirement - except perhaps the naive
approach many developers take of just processing based on QNames with
fixed prefixes, and ignoring the URI connection completely.
> 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,
That's simply false. QNames were created by the Namespaces in XML
specification, and are not necessarily an appropriate "type". They are
a notation for identifying markup. Sensible use of QNames would have
respected the usage presented by Namespaces in XML and avoided creative
and deeply complicating reuse. Calling something a "type" provides no
help for those of us who see typing systems to be a complicating problem
for markup rather than a simplifying solution.
In this case I'd say the QName type is merely an excuse for and blessing
of bad practice. I think I made that case back in March 2000, as
Kendall notes.
> which in turn
> would identify all element content and/or attribute values which were
> QNames. This means that using type-aware XPath 2.0 it would be
> trivial to locate all QNames in a document. Note further that any
> sensible API for type-information-bearing infosets will expose the
> _values_ of leaf nodes, which for QNames is defined as being a pair of
> namespace name and local name.
And those of us who find type-aware XPath 2.0 to be a minefield of
little value remain just as screwed as ever.
> I must say I find this article, and the anti-QName sentiments it
> quotes, quite bizarre. Why use two mechanisms to do the same thing,
> namely establish ownership/semantic scope for names? XML Schema
> should have erected an independent scoped mechanism for associating
> URIs with local names? Can you _imagine_ the outraged howls of
> "bloat, complexity, failure to learn from experience" etc. if we had
> suggested such a thing?
I must say I find the notion that defining types solves these kinds of
problems - magically importing additional information from the
surrounding document into an attribute value - to be extraordinarily
bizarre. I don't yet see a PSVI API that performs this magic
transparently, either.
If you want to associate a URI and a local name, there's an easy way to
do it: two attribute values. See, for instance, [1].
I thought it was already too late to fix this disaster in March 2000,
and I still consider it too late. Justifying this approach or claiming
that it doesn't exist seems to me a larger error than merely continuing
bad practice, however.
[1] - http://simonstl.com/projects/fragment/rules.xml
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com
|
