[
Lists Home |
Date Index |
Thread Index
]
Evan Lenz wrote:
> > 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.
What I meant by "not a lot of information" is that most documents only
use a few namespaces, so it wouldn't take up much memory. My hope was
that this could be determined at parse time and stored externally. It
could then be referenced as necessary. If this is not true/possible (and
it sounds like it isn't), then I definitely see what you mean.
> 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.)
But this makes it impossible for fragments of such documents to be
transferred with generic tools. The advantage (and it's really the only
advantage) of using xmlns attributes is that this is possible. (Or
should be -- the tools are still lacking.) I suppose it depends on the
application requirements.
> 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.
This is certainly true for XSLT, but doesn't apply to languages that use
QNames in values to represent graphs. For those languages, there is no
source and result, just a document, and the advantage of xmlns
attributes is the ability to cut out parts of the document (subgraphs).
Of course, this has to be done intelligently, since it is quite possible
that the subgraph is not contiguous in the document...
> > 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.
Actually, my point was that whenever you use any generic tool, there
will almost always be things you don't need that you have to deal with.
My hope (and experience) was that namespaces were pretty easy to deal
with. Annoying at times, yes, but not really that bad, since SAX and DOM
did most of the processing I needed. The fact that both you and Paul are
running into significant pain here is making me think otherwise.
-- Ron
|
