xml-dev - Re: Namespaces design implementation?

[james anderson <James.Anderson@mecomnet.de>]

Tyler Baker wrote:
> 
> I am sure this question has come up in private circles, but on this
> particular list the question of whether to integrate the current
> namespaces draft into the core of an XML parser/XML framework or else
> put it all in a layer on top of the parser/framework has not come up to
> date.

The topic has come up.

So far as I've been able to tell, the "resounding" preference has been for
layering it on top of the parser.

The opinion has not been universal, but I believe, I am correct in reporting
that a very limited number of correspondents have spoken up for alternatives. :)

> The reason I ask this is that right now I have to make a major design
> decision about how to integrate namespaces support into the
> parser/formatter I have been working on.  I have about 5 different
> implementation designs that I have worked up, each with their own
> memory, speed, and API ease of use tradeoffs, so figuring out the answer
> to this question is quite important.  XML can do a lot of great things
> without namespaces, so keeping namespaces as a separate and distinct
> layer gets my personal vote.  Nevertheless, I am a peon in the whole
> scheme of things who has no real input into this particular issue so any
> help in obtaining an answer to the previously stated questions would be
> greatly appreciated.

You do not describe your alternatives, but I would suggest that the real issue
is not whether namespace support is in a separate layer, but whether the
application operates on names which are strings or "something else". 

If the application does not need namespaces, it should well use a parser which
makes no assertions about the content of a name, other than (perhaps) that it
contain no more than one colon. If, on the other hand, the application
operates on a dom-like model, unless the application is "about" namespaces,
then it is not necessary that any part of the application know about
namespaces except that part which decodes and encodes objects. which part is
the interface to the parser - and the only interface to the parser.

Since, in that case the part of the "application" which handles namespaces is
effectively inseparable from the parser and, integral with it, from the point
of view of such an application, an explicit layering has no advantage. This
is, in any case, a minor issue.

The model for names is the more significant issue. 

My experience is that, if the application performs operations (a) on a
document model which (b) require that it observe namespaces, then it is going
to perform comparisons over collections of (at least) element names and
attribute names, and that these collections constitute a structured store, not
temporary operands for comparisons "on the fly". Once this is true, then it is
more effective for the parser to have interned the name at the point where it
was parsed and to pass such interned names through its interface to/from the
application, than it is for it to pass strings. The names are interned into
collections which, in turn, are identified by uri.
This mechanism puts the application in the position to
1) perform comparisons as an identity comparison rather than a string compare;
2) cache additional information (eg the dtd, the uri, the prefix at the time
interned, ...) directly on the interned name;
3) avoid having to manage element-specific prefix bindings - as is, for
example, suggested in the latest xsl draft. (for those following the namespace
discussion, this was the "indefinite extent" issue which I raised in one of my
six questions.)


> 
> ...
>
> I think the main question I have is, will the namespaces draft ever
> eventually be integrated into a future draft of XML, e.g. XML 1.1?
> 

This does not change the arguments above.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)