The Peace Process: DOM and namespaces...

[Tyler Baker]

Bill la Forge wrote:

> From: Tyler Baker <tyler at infinet.com>
> >The issue here is using the standard DOM interfaces to do the job.  If you subclass the DOM
> >and use this new type you defined to manage namespaces, then you might as well not use the DOM
> >at all because this is a proprietary feature.
>
> I am afraid I don't understand where proprietary feature comes in, nor the need for subclassing.
>
> Lets say I have an off-the-shelf parser (AElfred?) and an off-the-shelf DOM (Docuverse?).
>
> I'm writing a program that needs to use the DOM to process documents that use namespaces.
> So I wrap John Cowan's inheritance filter around the parser and feed the filter to the DOM.
> Then I write a static methods for fetching a qualified name from an element...
>
>     public static String getQualified(Element);

This is not the situation I am talking about.  I am talking about if you mutate the DOM object you
need to in effect do all of this stuff all over again.  This als only works from reading static HTML
files.

The core situation I am talking about is if you do things like:

Element element = document.createElement("foo:bar");

How do you resolve foo to a namespace unless you have some managed context for doing so.

> My application then uses this 5-line method to access the qualified names when it needs them.
> I then manipulate the tree as needed. When done, I walk the tree, generating SAX events,
> feed them through an uninherit filter, and compose a document from the result.

Walking an entire tree just to do this will cause problems for situations where performance is
critical.  Whether you are using C or Java, this is an expensive operation.

> Yes, my application is proprietary. It should be!
>
> But the interfaces are conformant. And the components are all conformant. And it was
> pretty easy to use all this conformant software to put together an application which
> pushes a document which uses namespaces through the DOM.

Yah, but you sacrifice real-world usability by throwing performance out the window.

> Isn't this the real strength of standards? Being able to get off-the-shelf software from
> multiple vendors, integrate them into an application, and do something real???

Yah standards are nice if they are practical in the real-world.  "Namespaces in XML" causes so many
headaches with other internet standards that I deem it not practical to use.

Tyler


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/ and on CD-ROM/ISBN 981-02-3594-1
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)