Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: Oren Ben-Kiki <firstname.lastname@example.org>
- Date: Mon, 08 Feb 1999 15:29:11 -0500
Oren Ben-Kiki wrote:
> Tyler Baker <email@example.com> wrote:
> >In effect "Namespaces in XML" either makes using the DOM completely
> useless. In fact, in
> >order for the DOM to be made useful in the presence of "Namespaces in
> XML" you would have to
> >make a lot of changes that are not backwards compatible with the Level 1
> recommendation. This
> >in practical terms would make using the DOM in an XSL Processor pretty much
> pointless (all XSL
> >Processors I know of other than XT use the DOM as the source tree, and some
> even use it as the
> >stylesheet tree as well). If you mutate the source tree, then everything
> is hosed.
> What's wrong with doing the '^' expansion when building the DOM? Names would
> become context independent, but still unique, using the current interfaces.
What I am saying here is that if you make a call to:
What are you to do here? Do you throw in an expanded name, or do you throw in a QName which
should be expanded by the DOM? These are not clarified:
For example if I wanted to create an xsl:text element for a stylesheet, would I do something
String prefix = "xsl";
String localPart = "text";
Document.createElement(prefix + ":" + localPart);
or else would I do something like:
String namespace = "http://www.w3.org/TR/WD-xsl";
String localPart = "text";
Document.createElement(namespace + ":" + localPart);
Of course the forward slash character is not a valid name character so you are pretty much
screwed as far as this is concerned. You would need to change the Document interface to have
createElement() be of the form:
Document.createElement(String prefix, String namespace, String localPart);
The prefix would be there for backwards compatibility. Namespaces are given as attribute
values and can in essence be character string you want. This is not the case with the Name
production in the XML 1.0 spec.
> Then a bit of magic to the output module: (i) keep track of 'xmlns'
> attributes, and emit names accordingly and (ii) either throw an exception of
> invent a prefix on the fly if you encounter a namespace which wasn't
> declared yet. Is re-working the DOM _really_ necessary?
Reading in XML and writing out XML is simple enough from the XML library developer's
perspective. Dealing with namespaces at the application level is a totally different
ballgame. The fact that some of the more relevant people here cannot see the obvious
complexities of "Namespaces in XML" when dealing with it at the application level leads me to
believe they either don't give a hoot about end-users using XML, or that they are out of touch
with the great majority of the developer community and web users in general.
> I _really_ wish this whole namespace recommendation was specified this way
> from the start.
The namespaces recommendation is relatively simple to understand from my perspective as an XML
tools developer (well not that simple as I had to reread the August draft about 10 times to
digest it all), however it opens many new cans of worms for all sorts of applications that
wish to use and support XML. It is that middle area between when XML is parsed into some
useful data structure and then reserializes it back to XML (i.e. the application) that really
concerns me here. The way I see it, the current recommendation does not even truly solve the
unique naming problem in XML content, but instead just adds an extra layer of indirection and
fragmentation to XML. In the end, all this ever does is make the task of using XML in web and
e-commerce applications much more difficult in the long run.
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)