Next Round

[Tyler Baker]

Chris Maden wrote:

> What, exactly, are the problems with the draft?  It provides a scheme
> for uniquely naming objects.  When I say, "html:a", I mean the anchor
> element from HTML; when I say, "faq:a", I mean the answer element from
> the FAQ ML.  Just like when, in the context of HTML, I say "p", I mean
> the paragraph from HTML.  If you know what to do with "the anchor
> element from HTML", you do it, if not, you don't.  Why are namespace-
> derived names harder to handle than any other system of naming?

It is not that namespaces are the problem it is the handling of them at the
application level, as well as the fact that using namespaces requires making
namespace declarations using attributes.  This would be fine for strict document
formats like HTML where you pretty much keep all of the relevant application data
as content, and you don't need to think of elements as a mapping of serialized
content to objects but for interchange (a potential of XML that the W3C to date
has pretty much ignored) where people use attributes for all kinds of different
things, adding in these namespace attributes makes processing at the application
level a pain.

For giant document formats like HTML, "Namespaces in XML" may not seem so bad at
first, but if you ever want to have a hope and prayer of using XML in non-trivial
forms of electronic commerce or object serialization, you better think twice
before even thinking about adding in these xmlns:* attributes.

> As far as I can tell, the biggest problem is the possibility that a
> prefix's meaning can change within a document.  But your processor
> should be operating on URI+suffix, not the prefix, and changing a
> mapping table can't be *that* hard.

That is easy to do.  It is not as much of a problem as it is sloppy.  Handling
this at the parser level is very simple, at the application level this is another
matter.  If someone with a non-trivial use of "Namespaces in XML" can refute my
claim by showing a real world XML based application (XSL processors not included)
that makes effective use of "Namespaces in XML" than please be my guest.  To
date, other than XSL, I have not seen any non-trivial use of the "Namespaces in
XML" recommendation or even talk about applications that will actually use this
namespaces mechanism.  Someone please show me the money here so I can see the
light into the motivation for the design of "Namespaces in XML".

> True, I'm not a sophisticated programmer, and I may be overlooking
> something.  But I have a hard time seeing Tim Bray and James Clark
> bulled by political pressure, even (especially?) from Microsoft.

These folks I have a lot of respect for, but I don't speak for them.  I have
never been to a W3C meeting so I don't know what kind of cigars are smoked at the
meetings (-:

Also, I don't think Microsoft wants to create something that does not work
either.  I just think that after all of the time that has been spent on
"Namespaces in XML" no one is brave enough to stand out and say "hey some people
have some real problems with this draft so maybe we should openly consider
alternatives".  Really for me it just all boils down to my impression that the
"Namespaces in XML" WG is afraid to admit that this recommendation is very much
sub-optimal and not ready for prime time.  I guess deadlines are taking priority
over common sense.

> In short, can we try to keep the discussion, at least on this list, to
> concrete technical issues?

Well, concrete technical issues or not, since "Namespaces in XML" is now a
recommendation, this essentially can be translated to "we will never go back on
this and you are stuck with it for eternity".  I very, very, very, very,
reluctantly will have support for "Namespaces in XML" in XML related projects I
work on, though I will probably never actively support it in terms of it being
something I think is "good" (unless of course it changes to something that is
more useful).

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/
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)