SAX2: Namespace proposal

[Tim Bray]

At 03:45 PM 12/18/99 -0500, David Megginson wrote:
>That said, I think that the best solution in SAX2 will be to allow
>either or both Namespace-qualified and raw XML names.  People seem to
>want both, and although I *strongly* disagree, DOM2 has decided to
>provide what should be irrelevant information about the original
>prefix used.

Actually, as I just finished arguing in response to your other note, 
I think what people care about is having the prefix/uri mapping available,
not knowing what prefix was actually used.  Have I missed something? Is
there an application scenario where you get

<a xmlns:a="http://x.com" xmlns:b="http://x.com">
  <a:foo /><b:bar />
  </a>

...and you actually care that the foo and bar had different prefixes?  
I'd find that really hard to believe.

In fact, the *only* scenario I can see in which you want the 
raw un-namespace-processed full name is where you are going to be doing
namespace-oblivious processing, and specifically the case in which you
are going to disregard the explicit warnings in XML 1.0 section 2.3
and use element names like a:foo and b:bar and would be upset if
intervening machinery picks them apart for you.

Anyone who wants to do that is IMHO nuts, but if they do, then since you 
thoughtfully provide a sax2 interface, then all they have to do is use
sax1 instead and they'll never have to worry about that terrible misguided 
namespace stuff, and they can mis-use colons to their hearts' content.

>Anyway, here's what I'm suggesting.  Please take a couple of Rolaids
>and maybe even a Gravol before you look at this, because while it's
>functional, it's not at all pretty...

I think that's often a symptom of having gone off the rails.  Sax1 is
not perfect but it's not aesthetically repellent in the slightest.

>1. From org.xml.sax2.DocumentHandler
>  public void startElement (String name, String namespaceURI,
>                            String localName, AttributeList atts)
>    throws SAXException;

Just lose the "name" argument to all of these, and add a facility
to query in-scope prefix-namespace mappings, and I think you've got
a winner.  

>Notes:
>a. A parser has the right to supply only cooked Namespace information, 
>   only raw XML 1.0 information, or both, as long as it does so
>   consistently.

Bleccch.  Gag.  Choke.  If you want raw XML 1.0 (and remember, this only
matters if you're misusing colons) why would you want to go near SAX2?

>b. The Namespace URI will be null when there is no Namespace declared
>   or none available.

Note that since the namespace URI can't be an empty string, it's worth
thinking about using "" rather than null.  It would allow you to do 
things like

 if (namespace.equals("http://my.namespace.com"))
   whatever();

instead of

 if ((namespace != null) && namespace.equals("http://my.namespace.com"))
   whatever();

but I haven't thought about this a lot.

>c. If the Parser is delivering raw XML 1.0 names, the Namespace
>   declarations (xmlns*) will be included in the AttributeList but
>   both the Namespace URI and the local name will be set to null, and
>   getType(String, String) and getValue(String, String) will always
>   fail (even with null arguments).

What!?!?!?  This seems baroque and totally wrong.  Why?

>d. There will probably also be a NamespaceHandler to report the scope
>   of Namespace declarations, but it may be possible to roll that into 
>   LexicalHandler.

Perhaps.  But why not just have a couple of new methods on the parser:

 String getURIForPrefix(String prefix)
 String[] getPrefixesForURI(String uri)

yeah, you'll have to stash a bit of state, but not very much.

James, that would give you what you need for XPath and so on, right?

>This is kind-of painful, I know, but please remember that SAX is meant
>to be the equivalent of a low-level device driver, not an elegant,
>high-level API 

Not good enough. Sax2 is going to be with us for a loooooooooooong
time.  Let's get it right.  -Tim


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/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe 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)