An XML Namespaces Alternative...

[Tyler Baker]

I like many other XML and XSL developers are very dissatisfied with the
most recent "Namespaces in XML" working draft.  However, some people it
appears think that the current draft is the greatest thing since sliced
bread.

Anyways, I am one of the people who actually liked the old namespaces PI
based proposal, mostly because it was simple and did the job in terms of
what a namespace is.

The current working draft though I dislike for several main reasons:

(1) Namespace declarations are declared using attributes.  This forces
programmers to explicitly use namespaces or at least handle the
namespace attributes even if they do not want to.  Some applications may
not give a hoot about namespaces, but will have a desire to parse
documents that are namespace aware without using some namespaces aware
XML Parser API or filter API.  SAX for example is not namespace aware,
so building some complicated inefficient filter to handle namespaces on
top of SAX really defeats the purpose of SAX in the first place (a
de-facto standard that is supported in just about every XML Parser
package around).

(2) Validating documents efficiently can be a problem with some uses of
"Namespaces in XML".  I don't want to reignite the giant thread on this
that popped up several months ago on xml-dev regarding this particular
issue, but there certainly is not anything close to a concensus on what
to do with DTD validation and namespaces.

Since I am probably one of the noisier people on this list regarding
this namespaces issue, I suppose it would be a good idea to put up or
shut up.  Simply complaining and moaning about why I or someone else
does not like namespaces in XML does not improve things at all though it
does release personal frustration.  I suppose the only thing I can do is
post to these lists an idea (call it an alternative) that borrows some
ideas from the previous proposal as well as the current working draft (I
am posting to XSL List because namespaces are a very important part of
XSL).  I hope that the fact that I am not a well-known SGML developer
with 10+ years of experience does not preclude me from trying to inject
some life into an issue that currently plagues XML and all of its
children.  I hope my comments are taken objectively and I don't receive
too many ad-hominem attacks which seem to be all too common in the
programming world when talking about technical matters (I as pretty much
everyone else is guilty of this from time to time).  Fortunately, these
two lists are some of the most polite technical discussion lists I have
encountered so far.

Now I have spent some serious time thinking about this issue as it will
be likely be very important that XML has an easy to use namespaces
standard for an app I have spent over a year and a half on that uses XML
extensively for all sorts of things.  I don't need to use XML, but I
feel it is for the most part simple, standardized, and easy enough for
end users to handle manually for such things like user profile data and
init files.

I think there is a pretty good concensus now among XML and XSL
developers that XML needs a namespaces mechanism, just that there seems
to be much disagreement about what the namespaces mechanism should be.
For the most part, I have heard a lot of negative criticism, and then
criticism of that criticism on the latest draft, but I have heard of few
public alternatives, so here is my attempt at taking a stab at XML
namespaces.

-----------------------------------------------------------------------------------------------------

In the previous XML Namespaces proposal (WD-xml-names-19980327)
processing instructions were used to declare globally applicable
namespaces.  The core objections to this approach from what I could
garner on xml-dev was mostly that the historical use of processing
instructions (processing instructions are supposed to be application
specific) suggested that you use processing instructions for things
which are not supposed to be core to the document and optionally ignored
by applications.  For lots of different reasons, I think that namespaces
should be optionally ignored but mostly because for most XML
applications, namespaces are not necessary at all (they complicate
things for the end user no matter how you cut it).  The other objection
to the last draft was the argument that the pi approach with global
namespaces had no concept of namespace defaulting.  Namespace defaulting
if done cleanly, I think would be a great utility to xml users.
However, the current draft I don't think does things cleanly.

The approach I have here has namespace defaulting (which still of course
has some problems with validation), does not need to use attributes and
should work more efficiently with SAX since you do not need to interate
through all attributes in an element or look up an attribute in a map of
attributes to see if a namespace declaration has been declared.  Also
you can undeclare a namespace which is something that the most recent
namespaces draft cannot do.

This proposal I think should obviate the need for the DOM to have any
special interfaces to handle namespaces and make it much more attractive
and efficient to use in XSL since all you need to do in an application
which uses the DOM is something like:

switch (node.getNodeType()) {
  case Node.PROCESSING_INSTRUCTION: {
    // Handle namespace processing here
  }
  default: {
    // Do something else
  }
}

rather than something like this which is a lot more inefficient:

NamedNodeMap attributes = node.getAttributes();
int length = attributes.getLength();
Node attribute;
for (int i = 0; i < length; i++) {
  attribute = attributes.item(i);
  if (attribute.getNodeName().startsWith("xmlns:")) {
    // This is a special namespace node so handle namespace processing
here
  }
}

A basic SAX filter that any programmer could use for namespaces (or they
could write their own) would be something like

  public void startElement(String name, org.xml.sax.AttributeList
attributes) throws org.xml.sax.SAXException {
    int index = name.indexOf(":");
    if (index == -1) {
      // Look up default namespace
    }
    else {
      findNamespace(name.substring(0, index));
    }
  }

  public void endElement(String name) throws org.xml.sax.SAXException {
    int index = name.indexOf(":");
    if (index == -1) {
      // Look up default namespace
    }
    else {
      findNamespace(name.substring(0, index));
    }
  }

  public void characters(char ch[], int start, int length) throws
org.xml.sax.SAXException {}
  public void ignorableWhitespace(char ch[], int start, int length)
throws org.xml.sax.SAXException {}

  public void processingInstruction(String target, String data) throws
org.xml.sax.SAXException {
    if (target.equals("xml:begin-ns")) {
      parseBeginNamespace(data);
    }
    else if (target.equals("xml:end-ns")) {
      parseEndNamespace(data);
    }
  }

  private void parseBeginNamespace(String data) {
    // Parse urn, name, and priority and
    // push namespace onto namespace stack and
    // remove the current namespace if it is a
    // sibling of this namespace
  }

  private void parseEndNamespace(String data) {
    // Parse name, and remove namespace with the
    // given name (ns pi's must be nested properly)
  }

  private Namespace findNamespace(String prefix) {
    // Continually peek at namespaces on the namespace stack until
    // one is found and return the urn associated with
    // that namespace
  }

There are already SAX filters for the current namespaces proposal (I
think John Cowan who lurks on xml-dev wrote one), but they are
inefficient because for each element you effectively have to search all
attributes to see if one of the attributes is a namespace attribute.
This in the general case will eat a lot of CPU.  The only real-world
alternative I can see is to not use SAX and do all of this natively in
the XML Parser (i.e. for each parsed attribute check it there to see if
it is a namespace declaration).  SAX is very successful so I see no
reason why anyone will use "Namespaces in XML" unless it is forced down
their throats in forthcoming sister XML drafts like XSL.

Anyways, here is a sample XML file that for the most part shows the
basic implementation of my namespaces idea.

<?xml version="1.0"?>

<!-- This will push A onto the namespace stack -->
<?xml:begin-ns name="A" urn="http://www.daisoft.com/schema-A"?>
<A:foo>
    <!-- This will push B onto the namespace stack -->
  <?xml:begin-ns name="B" urn="http://www.daisoft.com/schema-B"?>
  <B:foo>
    <!-- This will push C onto the namespace stack -->
    <?xml:begin-ns name="C" super="A"
urn="http://www.daisoft.com/schema-C"?>
      <C:foo>
      </C:foo>
    <!-- This will knock C off the stack and push D onto the namespace
stack -->
    <?xml:begin-ns name="D" urn="http://www.daisoft.com/schema-D"?>
      <D:baz>
      </D:baz>
    <!-- This will pop D off the namespace stack -->
    <?xml:end-ns name="D"?>
  </B:foo>
  <!-- Right here the default namespace is B -->
  <bar>
  </bar>
<!-- This will pop B off the namespace stack -->
  <?xml:end-ns name="B"?>
</A:foo>
<!-- This will pop A off the namespace stack even though this is not
necessary since we are at the end of the document-->
<?xml:end-ns name="A"?>

Most of this is pretty self-explantory however there are a few not so
clear things here.  One is the "super" attribute of a namespace
processing instruction.  This could be omitted, but I thought it might
be useful for object-oriented applications which need to delegate
(perhaps instead of "super" it should be "delegate") processing of a
content type to some other component.  In other words for:

    <?xml:begin-ns name="C" super="A"
urn="http://www.daisoft.com/schema-C"?>

If an element type cannot be found in the namespace of "C" then it will
delegate to the "A" namespace before throwing an error.  This is just an
idea that I think may help out object-oriented technologies so don't
take it too seriously for the moment.

You could even make it something like:
    <?xml:begin-ns name="C" super="B, A"
urn="http://www.daisoft.com/schema-C"?>

Where you would have multiple delegates.

For frameworks like Coins, this sort of feature may open up a whole lot
of creative possibilities for dynamically assembled applications (I am
not speaking from the seat of my pants here as I have an entire GUI
based application I have written which has most of its GUI glued
together dynamically using XML and Java).  Who really knows, but I think
it is an avenue of exploration.  I have not really looked into the
negatives of this "super" attribute idea too much so please don't beat
me up too bad if I have seriously overlooked something here.

Other ideas I have are global namespaces, priorities and lots of other
things, but my goal here is that the W3C produce a simple, clear,
proposal that my fox terrier could understand upon a first read (-:
Namespaces should be simple, so we should keep what comprises namespaces
simpl.

All in all, I think this approach is much simpler to implement
(especially in scripting languages like PERL) and much easier to use
than what is currently drafted.  Most importantly, it does not use
attributes which is one of the number one annoyances of the current
draft.  Of course this is all just my opinion, so hopefully this will
start a thread of serious debate on what sort of namespaces mechanism we
the developers would like the W3C to implement instead of us folks
critical about the latest namespaces draft just complaining about it.
Of course if the W3C totally ignores the needs to the non-member
developers, it will lose a lot of credibility and respect that any
standards organizations holds dear.  I doubt the W3C is the ivory tower
so many people claim it to be, so I guess solving this namespaces
problem in the next couple of months will be a major test.

Regards,

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)