Altova Mailing List Archives

Re: SAX: Next Round (Namespace support)

From: james anderson <James.Anderson@--------.-->
To: "xml-dev@--.--.--" <-------@--.--.-->
Date: 1/25/1999 4:04:00 PM
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@i...
Archived as:
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.