SAX: Next Round (Namespace support)

james anderson James.Anderson at
Mon Jan 25 16:03:56 GMT 1999

I would like to pose the question: "why is this separator necessary?".
I am aware, that the tendancy is to drag the URI's around as an immediate part
of the universal name.
Which leads to the "out-of-band" separator.
But... Why is it necessary to catenate the URI with the local part of the name?

In other words, if it is a matter of implementation, I wonder why it isn't a
really good idea to intern the names into collections which are named by URI.
If that happens - whether immediately while parsing or later "within the
application", then the intermediate catenated form is unnecessary.

At the least, wouldn't it be better to leave this decision (both whether to
catenate, and if so with which separator) to a name factory - so long as the
resulting instances conform to the interface which yields local, uri, and
universal names?

John Cowan wrote:
> James Clark scripsit:
> > However, I wonder whether it's really a good idea to allow apps to
> > choose the separator. It makes it harder to chain together SAX processes
> > using things like the Filter.  If one DocumentHandler expects names
> > separated by # and another expects them separated by !, then they can't
> > work together without some additional glue. I think consideration should
> > be given to mandating a specific separator character. It's not obvious
> > to me what the right answer is here.
> The criteria I used were:
> 1)      must be ASCII
> 2)      must not be whitespace
> 3)      must not be valid in a URI
> 4)      must not be valid in an NCName
> 5)      must not commonly appear after a URI (#, |) or before an NCName(:).
> The result?  Circumflex.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list