[XML-SIG] operating modes (was: SAX Namespaces)

Greg Stein gstein@lyra.org
Thu, 6 Jul 2000 15:44:03 -0700


On Thu, Jul 06, 2000 at 11:08:31AM -0500, Paul Prescod wrote:
> Back to startElement. I'm not entirely happy with any of the choices
> before us. The status quo is probably not much better or worse than
> anything else so we might as well leave it. That means:
> 
> def startElement( self, (URI, localname), rawname, value ):
> 	....
> 
> I propose a design goal: "Code that is namespace-unaware should work the
> same whether namespaces are turned on or not." This allows an
> incremental upgrade from namespace mode to non-namespace mode.

Seems reasonable. I'm okay with this.

> If we accept that goal, then rawname should be rawname, not prefix.
> Namespace-oblivious code should work with the rawname and ignore the
> "namespace name" parameter altogether. Making Expat live up to this
> expectation could be a headache, but I think that it is useful. The
> documentation should describe the rawname parameter as the appropriate
> one for people uninterested in namespaces.
> 
> If you know about namespaces, and want to make code that works the same
> in namespace mode or non-namespace mode, then you can match on the first
> parameter, which would be either ("URI", "localname") or just "name". If
> you don't care about namespace mode then you can just configure your
> parser to always use namespaces and presume that the value is a tuple.

These two paragraphs seem wrong. Given:

    def startElement(self, name, something, value):

The code should simply use "name" for all name references. That works in
both non-namespace and namespace mode.

*If* the user is building namespace-aware code, *then* they look at the
"something" parameter. IMO, that second parameter is a prefix, but that does
not negate standard operating procedure: key all your work off the first
parameter.

I don't see how it would be possibly to write any code using a rawname when
in NS-mode. That prefix could be anything.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/