Why SAX needs namespace support

[james anderson]

Tyler Baker wrote:
> 
> ...
> 
> Implementing namespaces in an XML parser is a trivial task, but dealing with
> namespaces at the application level is a totally different story, especially with
> this namespaces scoping stuff.  How do you deal with namespaces in the DOM?  I
> mean if you copy a node here, and insert a node there, this entire namespace
> scoping stuff gets all out of whack.

It gets out of whack only if one models it incorrectly. Does anyone here even
know what the "upward funarg" problem is?. In any case, it has yet to be shown
that it is necessary to handle the scoping in the DOM at all, as the
identifiers in the DOM should be universal names.

>  Of course you could say "well the
> application programmer will just have to deal with that" and then the application
> programmer would say "why should I deal with it at all".

No. The better implementation is intrinsic in the parser. Then the problem
does not exist on the application level. .

> ... I have had to create my own Java <--> XML architecture
> because nothing out there is suitable for my needs or the needs of developers who
> will hopefully be working with this client application.

You need only ensure that all identifiers you use are universal names. It is
unfortunate that current parsers still model identifiers as strings. I would
hope that this will change. As long as the serializer does the inversion
mapping to that which the parser did, the application has nothing to do with
scoping issues.

> 
> OK the point is, namespaces as they are currently defined I feel make practical
> use of XML in this regard too difficult for developer novices to deal with.  I
> would not even have wasted a year of my life on XML if I thought that its goals
> were targeted exclusively for the browser centric world because that world does
> not apply at all to how I am using XML.  XML 1.0 did the job.  Namespaces do
> not.

If namespaces do not do the job, then the application presumes an inadequate
model for universal names. Which has nothing directly to do with their
encoding in XML.

> Plain and simple "Namespaces in XML" looks ugly,

You are correct on this one point.

> ... feels ugly, and therefore is not
> practical at all for lots of applications that need to be simple, yet need some
> namespaces mechanism nevertheless.
> 
> Yes your customers, but that is in the document world.  You are right they
> probably could care less.  Perhaps I should scrap XML support altogether and
> stick with just Java Object Serialization.

The problem of uniquely identifying names does not disappear if you take this
approach. The serialization form changes. That is all. The requirement, that
you model them adequately in the application, does not.
> 
> Yah, but try and use namespaces with dynamically built DOM trees (or any other
> object tree implementation that maps to XML).

Go back and look at the note which I posted just before Christmas on "External
DTD & namespaces". The DOM manipulation and the serialization are the easy part.

> ... It can be a major pain in the rear
> if you have multiple components that have no knowledge of each other and whose
> externalized content is merged into one XML document tree.

This claim is not correct. The serialization is actually the easiest part of
the problem.
Yes, the proposed serialization form for prefix bindings is convoluted. The
distinctions between kinds of namespaces is baroque. These things do not
matter to an application. It is the job of the parser to get these right and
to map the qualified names to easily managed internal representations for
universal names. Once that is accomplished, there need be no special coding in
the application to accommodate namespaces.

> ... Just think of the
> nightmares of managing namespace defaulting if you are merging a lot of abstract
> content (perhaps E-Commerce transactions which are converted to a
> DocumentFragment).

I would not expect any. Modulo the provision for a null namespace, the
PR-specified encoding assures that, if an identifier has an universal
equivalent in isolation, it will retain the same equivalent in any context. It
does permit identifers which do not have an "intrinsic  equivalent" to be
captured upon reference, but also provides the means to specify the mapping.
Where's the prospective nightmare?
> 
> ...  Try using XML with namespaces
> for anything else more sophisticated and you might as well forget it (especially
> for E-Commerce).  But yes, "Namespaces in XML" may in fact flourish in the web

I have tried. I do use it. One would not be able to do "anything else more
sophisticated" than a browser without it.


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