Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Bill la Forge <firstname.lastname@example.org>
- Date: Thu, 11 Feb 1999 18:24:33 -0500
Bill la Forge wrote:
> From: Tyler Baker <email@example.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
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.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)