[
Lists Home |
Date Index |
Thread Index
]
Ron Bourret wrote:
> Evan Lenz wrote:
>
> > 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.
>
> But that's hardly a lot of information, is it?
It is for any specification or tool that's intended to support general XML.
Take XQuery, for example. In-scope namespaces, whether as specified in XPath
1.0 or otherwise, represent a large storage and/or run-time burden in
comparison to the extent to which they are actually needed (i.e. when QNames
are used in attribute values). When copying an element, all of the in-scope
namespaces must be determined and copied along with it. That either means
replicating namespace nodes for each of every element's in-scope prefix-URI
bindings (as XPath 1.0 does) or specifying an elaborate namespace fixup
algorithm by which the in-scope declarations are identified and new
declarations are appropriately added to the result. The semantics of XQuery
element constructors becomes unwieldy. That [in-scope namespaces] is part of
the Infoset isn't much consolation. Like Canonical XML, it's just taking its
cues from other specifications.
Perhaps what's needed is some serializable bit (PI?) that indicates whether
[in-scope namespaces] are significant or not. Of course, the default would
probably have to be the status quo, i.e. that they are. Then, XML database
users would be advised to add <?xmlns preserve="no"?> to the beginning of
all documents except XSLT stylesheets, XML Schemas, WSDL documents, etc.
<snip/>
> > If each layer had its own
> > namespace declaration mechanism (one for element/attribute
> names, and one
> > for application-specific content), then it would always be
> possible to throw
> > away scope information as purely lexical detail.
>
> Yes, but the end result would be that many applications would end up
> reinventing xmlns attributes.
I think that application-level namespace declarations would look a lot
different than xmlns declarations for a number of reasons:
Most applications (that use QNames in content) will not need the generality
of xmlns scoping. For example, in XSLT, users almost always attach all
namespace declarations to the xsl:stylesheet element. An application-level
declaration such as a top-level instruction listing prefixes and URIs should
meet 99.9% of use cases. (You could still use xmlns wherever you want for
literal result elements; this is only for QNames in XPath expressions.)
Furthermore, it would make complete sense from the user's perspective to
separate the two namespace declarations. One (xmlns) would be used for
literal result elements, i.e. the result tree. The other (say,
xsl:namespace-decl) would be used for referring to elements by name, i.e.
the source tree. If you're translating from XHTML to XHTML, then, yes,
you'll have to repeat similar declarations. Most often, however,
transformations go from one vocabulary to another. When they do, in XSLT
1.0, users are forced to use the exclude-result-prefixes attribute to get
rid of unwanted namespace declarations in the result. They appear there
because of namespace declarations in the stylesheet whose only purpose was
to resolve QNames in XPath expressions. The user has to explicitly clean up
after this overloading of namespace declarations to do two very different
things.
<snip/>
> How are they being "forced" on applications? DOM doesn't do this (which
> I think is a mistake), and it's trivial to ignore this information in
> SAX if your application doesn't need them.
>
> Put another way, I don't care about entity usage. Should I also complain
> that entities are being forced on me?
Good question. I think this is pretty different. For one thing, entity
boundaries are not in the Infoset, whereas in-scope namespaces are. I can't
think of any XML vocabulary that's interpreted differently based on whether
entity boundaries in the instance are discarded, let alone break if they are
not preserved. (Are there any?) But that's precisely what happens when
in-scope namespaces are not preserved. Thus, general-purpose XML
applications, such as XML databases, query languages, transformation
languages, etc. *are* forced to deal with in-scope namespaces as part of the
data model, but they are not forced to deal with entities as part of the
data model, at least not by any W3C precedent that I've seen. (Note that
being forced by necessity to support something is different than providing
support as an added value.)
Evan
|
