[XML-SIG] SAX 2.0, again

[uche.ogbuji@fourthought.com]

> > The first problem is that of how to represent XML names. SAX 2.0 can
> > handle namespaces, and so we must somehow represent namespace-names.
> 
> I think we should make it as easy as possible to use either namespace-style
> names or ordinary names, so both can be used in the same way as far as
> possible.  The application shouldn't have to figure out the structure before
> it can even extract the value.  So I don't think the xml name should be a
> tuple if it has a declared namespace but a string if there is no namespace.
> 
> With this in mind, how about
> 
> ((prefix,localpart),uri)
> 
> If namespaces were not being used, prefix and uri would be None (or possibly
> the empty string).

It would have to be the former, to avoid confusion with default namespaces and 
null NS in an NS-aware system.

> This allows the use of alternative values for the prefix
> (so you could, for example, use xslt:template for xsl:template if you wanted
> to, which is the way it is supposed to work), and you could check the uri
> value anytime you needed to learn the exact namespace.  localpart would
> always be a string.

This is pretty much essential.

> Also, if you had a document containing several prefixes for the same
> namespace, you could easily use the localpart and uri, rather than the
> prefix.

The prefix shouldn't be used except for convenient uniformity from input to 
output, and for the few W3C-sanctioned cases such as XPath name tests.

> I don't recall how it shook out on XML-DEV, but there were a number of posts
> that said it was important to keep the actual prefix value, and this
> approach would do that.

I was a champion of that on XML-DEV, for the above reasons.

> BTW, "uri" doesn't actually need to be a uri, any unique string will do.

Actually, it does have to be a URI or it is in contradiction of the spec 
(although they didn't go the natural step to make URI conformance a formal 
namespace constraint, they do have pretty conclusive wording to that effect in 
section 1).


-- 
Uche Ogbuji
Fourthought, Inc., IT Consultants
uche.ogbuji@fourthought.com	(970)481-0805
Software-engineering, project-management, knowledge-management
http://Fourthought.com		http://OpenTechnology.org