SAX2: summary of Namespace-support arguments

[David Megginson]

Thanks to everyone for their input on Namespace support in SAX2.  A
few identifiable positions have come up:

1. SAX2 should provide no special Namespace support at all, because
   applications can use the xmlns* attributes to get at information
   they need.

2. SAX2 should provide Namespace-qualified names as single strings.

3. SAX2 should provide the Namespace URI and the local name
   separately.

4. SAX2 should provide the Namespace URI and local name separately,
   and should also provide information about the original prefix used
   for each element or attribute name.

I will arbitrarily and high-handedly dismiss #1 out of hand -- since
Namespace processing is a prerequisite for XSL, RDF, XML Schemas,
XHTML, DOM2, and just about everything else interesting happening in
XML right now, there is an obvious benefit in not forcing every
application writer to write custom code for the same task -- SAX2
*must* expose cooked Namespace information if it's going to be useful
with the next generation of XML specs and apps.

That leaves us with three positions, which I will assign to their most 
outspoken (though not sole) advocates and will attempt to summarize,
probably incorrectly:

#2 (Simon St-Laurent)
  SAX should be as simple and transparent as possible: it's easy
  for applications to work with a single string rather than a new
  class of object, and using a single string keeps SAX2
  backwards-compatible.

#3 (James Clark)
  James sympathizes with the backwards-compatible argument because
  he's done the same with Expat, but he believes that SAX2 should
  present what are in effect compound names as compound objects.
  James would like to create a new Name class that includes the
  original prefix (if any) as well as the Namespace URI and local
  name.

#4 (Tim Bray)
  Tim agrees that a compound object makes the most sense, because it
  makes no sense for the parser to put the two parts together into a
  string only so that the app can take them apart again.  Tim argues
  that the original prefix shouldn't matter at all, and that apps
  should see only the cooked Namespace info: the Namespace URI and the 
  local part.

(I should note that James and Tim have been conducting this friendly
debate -- prefix does/doesn't matter -- for quite a while and in many
contexts other than SAX2.)
  
To rephrase, then, there are actually two different decisions that we
need to make:

1. maximal vs. minimal Namespace information; and
2. String vs. compound-object representation.

I'm going to post my suggestion in a separate message, and as with
most of the rest of SAX, while no one will like it, I hope that
everyone will be able to live with it.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

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)