Restricted Namespaces for XML

[Tyler Baker]

Don Park wrote:

> This is not a proposal but a testing of the water to see if there is a wide
> enough need for a 'restricted' (some might call it constricted) version of
> the "Namespaces for XML" spec (lets call it RNX for now).
>
> Such a spec might dictate that all namespace declarations be at the root
> element (XML fragments are problematic but...).  This restriction has the
> side effect of not allowing duplicate prefixes.
>
> Comments?

Of course this is very much like the old PI approach will may have been brutally simple, but
this I think was a good thing.  There are many other ways of assuring that all Names in a
document are unique that make much more sense than "Namespaces in XML", the simplest being
that element types have some unique identifier prepended to your general name type.  Perhaps
this adds a bit to the total size of XML documents.

For example if I wanted to represent some element that mapped to a java.awt.Rectangle class I
might have something like:

<java.awt.Rectangle x="0" y="0" width ="100" height="100"/>

In this case the convention is package name + '.' + class name.  With a DTD you are already
there.  It is really that simple.  If you want to use a domain name plus some path, you could
have something like:

<www.amazon.com:books:history title="The History Of Europe"/>

where you merely replace path separators with ':'.

Of course namespaces (the old simple PI based approach) I think would help a lot in search
engines as they would only have to scan the prolog of the document to see if any well-known
namespace elements are used in the document.  Perhaps we can take a vote on this list to see
whether people like the old PI based namespaces proposal better than how things are currently
defined.

Nevertheless I really like this RNX idea you are proposing.  I am not against namespaces per
se (most XML applications I don't think will ever need any namespaces mechanism though), but I
think that the final decision makers of "Namespaces in XML" somehow neglected the myriad of
already noted problems with "Namespaces in XML" as things now stand.  If they will ignore the
total lack of concensus on this issue, then it is likely their efforts in the future will be
ignored.  Right now I have to spend a lot of otherwise unnecessary time dealing with
implementing a very complex, somewhat inefficient hack to implement namespaces in an XSL
Processor I have been working on so that I can have support for the DOM has well.  The
alternative is no DOM source tree support or else building a proprietary source tree structure
as in the case with XT.  Koala and LotusXSL have support for namespaces, but they have chosen
an implementation path I chose to ignore a long time ago because it causes major performance
problems.  At this stage in the game with XSL, I doubt that Jeremy Calles or Scott Boag care
much about performance.  Most XSL users I feel now are very early adopters and are just
getting familiar with stylesheets and the XSL processing model, so performance is not such a
big issue to get all excited about at the moment.

Right now XT is the only released XSL processor that has decent performance IMVHO, however
since XT has no DOM support at all, I am not sure how useful it is in most production
environments at this point (XSL is still in its infancy so a lot of things could change in the
future that may cause all XSL Processor developers to totally change their design altogether).

Since XSL still has 6 months before it will probably become a recommendation, none of these
namespaces issues I feel matter too much right now, but if they are not addressed sometime
soon, they will cause major problems down the road.  Of course the DOM could change to provide
native support for namespaces, but Level 1 is a recommendation now (i.e. immutable).  My faith
in the W3C right now is at an all-time low, so my guess is that the DOM will not change,
"Namespaces in XML" will not change, and XSL plus the DOM will be a pain to deal with because
of needing to support "Namespaces in XML" without incurring too much overhead.  So in the end
XSL users suffer by needing to throw extra hardware to use XSL to operate their web sites and
that is a shame.

A member on this list (I forget who) was talking about why they use expat and not XSL right
now and their number one concern was performance (they basically said that they were getting
120X performance gains with the expat approach which no matter how you cut it is
significant).  I am not sure how much overhead namespaces support will add right now to my
particular XSL implementation (it is hard to say because I am using a trick/hack that is hard
to pin down in terms of O notation), but I would not even have to deal with this if the old PI
based approach was used.

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)