[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Fw: "Clean Specs"

  • From: Tyler Baker <tyler@i...>
  • To: Oren Ben-Kiki <oren@c...>
  • Date: Mon, 08 Feb 1999 15:29:11 -0500

createelement namespace
Oren Ben-Kiki wrote:

> Tyler Baker <tyler@i...> 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:

Document.createElement(String name);

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
like:

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.

Tyler


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.