Why SAX needs namespace support

[Tyler Baker]

david at megginson.com wrote:

> Michael.Kay at icl.com writes:
>
>  > > "Namespaces in XML" seems to be going down this path as no
>  > > one will admit that it is a massive failure.
>  >
>  > I agree with you that "Namespaces" is technically inelegant, it
>  > also has the problem of being incompatible with a lot of other XML
>  > things. Unfortunately, though, I think it is doomed to succeed.
>
> I agree.
>
> I also object strongly to the inelegance of attribute-based namespace
> declarations and to the unnecessary complication of local namespace
> scoping (which, like optional external-entity expansion in XML 1.0,
> tries to solve a straw-man problem that turns out not to exist in any
> serious way anyway).

I never quite understood why attributes are used for namespace declarations as
well.  I also agree with the

Implementing namespaces in an XML parser is a trivial task, but dealing with
namespaces at the application level is a totally different story, especially with
this namespaces scoping stuff.  How do you deal with namespaces in the DOM?  I
mean if you copy a node here, and insert a node there, this entire namespace
scoping stuff gets all out of whack.  Of course you could say "well the
application programmer will just have to deal with that" and then the application
programmer would say "why should I deal with it at all".  As someone who has
written an XML parser, DOM implementation, XSL processor, and a client-oriented
application that I consider to be in the "major" category, I find XML to be very
useful as an alternative externalization format to Java Object Serialization for
Java objects.  All of what you might call "business objects" (this is not a
business application but a consumer application) can be expressed in Java Object
Serialization (I use this for over the wire object state transfer) or XML (I use
this format mostly for spitting out object state to a file since XML is simple
enough that many of the properties of the objects can be edited manually as well
as the fact XML is much more user friendly for other developers to interoperate
with than the binary streams which come out of using Java Object Serialization).
These "business objects" are not hardcoded in any particular hierarchy and to
support building an XML element tree (effectively elements are mapped directly to
these business objects) I have had to create my own Java <--> XML architecture
because nothing out there is suitable for my needs or the needs of developers who
will hopefully be working with this client application.

OK the point is, namespaces as they are currently defined I feel make practical
use of XML in this regard too difficult for developer novices to deal with.  I
would not even have wasted a year of my life on XML if I thought that its goals
were targeted exclusively for the browser centric world because that world does
not apply at all to how I am using XML.  XML 1.0 did the job.  Namespaces do
not.  Of course I could just elect not to support namespaces at all in this
application environment, but somewhere down the line, developers will need some
sort of namespaces mechanism here.  I also don't want to have to develop some
namespaces mechanism myself or else use a better alternative that someone else
has developed hat perhaps I feel is more suitable to component oriented
applications and then have to essentially badmouth the W3C by essentially saying
"well they have no clue when it comes to the developer community at large".  That
does not make me look good, but what else can I honestly say when someone says
"well why don't you use "Namespaces in XML" for this application environment.  I
can tell them the truth or I can make something up.

Plain and simple "Namespaces in XML" looks ugly, feels ugly, and therefore is not
practical at all for lots of applications that need to be simple, yet need some
namespaces mechanism nevertheless.  In this regard "Namespaces in XML" is already
a massive failure because it is limiting the target audience of XML altogether.
I am a huge fan of XML like probably everyone else on this list, but "Namespaces
in XML" has dampered my enthusiasm for this fledgling technology.

> That said, my customers couldn't care less -- they need the ability to
> provide globally-unique names that their software can disambiguate
> from other people's names, and for that purpose, XML Namespaces turns
> out to be useful far beyond initial expectations, warts and all.

Yes your customers, but that is in the document world.  You are right they
probably could care less.  Perhaps I should scrap XML support altogether and
stick with just Java Object Serialization.  I seriously doubt that will ever
happen because I can see that XML (minus namespaces) is the perfect solution to
storing object state in a human manageable context.  XML right now is simple
enough that non-programmers can edit an XML file manually.  Add in all of these
computer-science geekified additions to XML and a lot of people on this list who
are authors of XML books will find their book royalties dwindle to nothingness.

> The nicest part is that the utility of namespaces does not depend on
> any fancy, yet-to-be-written schema support for compound documents --
> for an enormous number of applications, it's enough just to be able to
> identify a globally-unique name.

Yah, but try and use namespaces with dynamically built DOM trees (or any other
object tree implementation that maps to XML).  It can be a major pain in the rear
if you have multiple components that have no knowledge of each other and whose
externalized content is merged into one XML document tree.  Just think of the
nightmares of managing namespace defaulting if you are merging a lot of abstract
content (perhaps E-Commerce transactions which are converted to a
DocumentFragment).  Of course if I am living in the browser world, then none of
this matters because in the browser world everything is one big document and
hardcoded into some visual context whether it be HTML or the forthcoming
Formatting Objects of XSL.

> Despite my initial pessimistic predications (some of you might
> remember that I also predicted the imminent death of Linux back around
> 1992 because of its monolithic kernel architecture), I am now
> confident that namespaces will succeed, and want some kind of
> namespace support in the next version of SAX.

I agree here, but I think namespaces will only succeed in the browser world.
Most people are using XML for just HTML related stuff anyways, so for the short
term future "Namespaces in XML" will do the job.  Try using XML with namespaces
for anything else more sophisticated and you might as well forget it (especially
for E-Commerce).  But yes, "Namespaces in XML" may in fact flourish in the web
browser world.

Nevertheless, we need to make sure that support of "Namespaces in XML" is as
painless as possible to the application developer.

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)