xml-dev - Re: "Clean Specs"

[Tyler Baker <tyler@infinet.com>]

Ronald Bourret wrote:

> Tim Bray wrote:
>
> > And as regards the namespace spec, I think that some people on this
> > list are substantially full of shit, and are wilfully refusing to see
> > how simple it is because it does not meet their own design prejudices.
> > I think that spec is *way* better than the XML spec.
>
> I've quoted this out of order because I think it is a very important point
> and one that has bothered me during this whole discussion.  Tim is
> absolutely correct here -- the namespaces spec is *way* better than the XML
> spec.  There is absolutely no comparison, both from an organization and a
> writing (sentence-level) point of view.
>
> I think there are three other things to remember with respect to the
> namespaces spec.  First, no matter how you cut them, namespaces turned out
> to be far more difficult than any of us could have imagined.  We didn't, as
> is the case in most programming languages, simply get them for free based
> on where we declared our variables -- we had to decorate variables
> ourselves.  Thus, I think the discussion has often confused frustration
> about technology with frustration about spec writing.
>
> Second, watching a spec evolve is not always the best way to judge how good
> it is.  Throughout this discussion, I have wondered how I would have felt
> about the namespaces spec had I seen it for the first time in its completed
> form.  No doubt I would have had some confusion, but I also would not have
> been carrying pre-conceived notions from one version to the next, which is
> where a lot of my confusion about the relation between attributes and
> namespaces came from.
>
> Finally, we have to remember that namespaces appear to work -- I have yet
> to hear any examples on this list where they don't.  Until such examples
> arise, I think we have more to gain by agreeing to use namespaces than by
> going off in our own directions.

Well, that depends on what you define the word "worK" is.  If you define working as being able
to run some pregenerated example, then I guess they work.  If you define working as being
manageable at the application level then "Namespaces in XML" is totally broken.  Take for
example some of the current DOM implementations, for instance Oracle and SUN's.  Both allow
you to build a DOM Document from a file using namespaces, but if you want to mutate the DOM
tree, you are in a quandary because the node name (which in namespaces parlance is a QName)
has no context to resolve the prefix.  Furthermore, if you copy a node and insert it somewhere
else in the document.  The DOM Element and Attr interface would need to have a method such as:

void setNodeName(String prefix, String namespace, String localPart)

as a hack just to make things barely work.

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.

Beyond the DOM, in application frameworks which have some serialization to XML mechanism for
components or whatever, you now will have output with random prefixes which makes XML about as
attractive to use as EDI transactions.  Just to figure out what the heck you are working with
requires hunting the entire document for instances of "xmlns:".  Some may shrug this off as
"so what" but if someone is using someone else's data and some problem is encountered,
manually mapping these prefixes to something tangible like a namespaces is quite a chore.  It
is almost the same has hunting down memory memory leaks when using languages with pointers.
Java does not include pointers for the main purpose of removing memory management from the
programmer.  "Namespaces in XML" now gives us prefix management or even namespaces management
depending on how you look at it.

As someone else pointed out earlier, we'll see if anyone "that is end-users and web sites"
will ever bother making their lives more difficult by using "Namespaces in XML" for developing
web-site content.  My odds on bet is everyone will be marching in lock-step to support
namespaces, but no one will ever actually use it (kind of like what happened with the "push"
and "channels" craze between MS and Netscape in 1996).

Tyler


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