xml-dev - Namespaces Revisited...

[Tyler Baker <tyler@infinet.com>]

One thing which I find perplexing is that we are discussing how to add
namespaces to XML when there are no real XML apps out there that I am
aware of who have wrestled with this issue.  In other words, despite
everyone crying about standards bodies being too slow, perhaps in this
case the WG is being too fast.

Until real XML applications come out and provide their own proprietary
uses of namespaces at the application level, we will all not have much
of a clue about how application developers are using namespaces and how
application developers have implemented namespaces.

My initial understanding of namespaces was that it was a way of
associating some particular element name in conjunction with a prefix of
some sort to identify a UNIQUE form of data.  In this sense, XML is more
useful as a data container than as a document model, since a document
viewer generally has some sense of how to render all of the elements
that is presented to it.

In Java at least, I had some creative ideas as to how to dynamically
instantiate element handlers by class name.  The class name would be
constructed by using its prefix as a key to lookup the application
specific package name plus any other prefix data for the class name and
combining it with the element name in the document.

In other words if I had a namespace prefix:

java.awt

and I had a replace value for the prefix:

com.dais.awt.X

If I had a namespace name:

java.awt:Dimension

I would get as a result the class name:

com.dais.awt.XDimension

which would likely be a subclass of java.awt.Dimension


With the current namespaces proposal, it does nothing for me and I am
having a very hard time trying to figure out if it will ever do anything
for most applications.  If you look at previous standards like OpenDoc,
they generally failed because no one used them.

For the particular app I have I have chosen to embed documents within
documents instead of futzing around with all of this namespaces stuff
and believe it or not it all works quite nicely.  Part of the reasons
for this are application specific (for example some objects are
dynamically created and the content within a document can only be
applied at this particular time) but nevertheless it works.

All of this talk about extending DTD's and element type inheritance
seems to totally ignore the question of possible implementation.  An
idea is just an idea until you something concrete behind it.  XML has
the years of success of SGML behind it, but this namespaces stuff has
nothing behind it.  That is why I plead for us all to go slowly with
namespaces as there seems to be much disagreement about it now.

Standards are usually built upon some sort of concensus.  If a standards
body uses a top-down approach to publishing standards, then they will
lose a lot of respect really fast among the average ISV who likes a
standards body pushing drafts down their throat (unless it is of the
alcoholic kind) about as much as having standard shoved down their
throat by some very large monopolistic ISV.  The secrecy process that
the W3C goes through makes me wonder sometimes if the W3C is simply a
corporation responsible to its shareholders (those who fork over the big
bucks to become members) rather than a real standards body for the
betterment of computing.

If the standards process that namespaces goes through were anything like
the process that of SAX or XSchema (which to an official standards body
may be considered barbaric), I think that namespaces would be much
further ahead and there would be many more people happy with it.  No
matter how many geniuses you have working on some standards draft in a
closed forum, it is my opinion that you will rarely do better than a
forum of collective opinions of those who actually need to work with
that standard.

Once you take the politics out of a standards process and only
concentrate on being pragmatic, it is amazing how successful standards
endeavours can become.

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