[XML-SIG] SAX Namespaces

[Greg Stein]

Minor mistake on my part:

On Mon, Jul 03, 2000 at 09:08:39PM -0500, Paul Prescod wrote:
> Greg Stein wrote:
>...
> > 
> > > The rawname *is* the element type name.
> > 
> > No, the element name is the (namespace, element-name) tuple. 
> 
> You won't find that in any XML specification.

The XML Namespaces spec states that the URI and the localname form the
complete, unique element name.

>...
> > > #1. I don't fundamentally believe that people will be doing this at the
> > > SAX level.
> > 
> > I do it all the time (although I don't use SAX). These kinds of comparisons
> > are quite common, and I am certainly not going to use some magic tools that
> > simplify it for me.
> 
> What are you talking about? I didn't propose any magic tools.

If I'm not making the URI/name comparisons myself, then something else is.
Just what were you thinking to do this? If not an "if" statement, then I
presumed some handy-dandy block box.

>...
> > or:
> >   def startElement(self, name, attrs):
> >       if name == xslt_ns:
> >           # do something useful
> 
> That isn't an option. We need the prefix or qname. Plus, I'm not even
> sure why you would be comparing a whole name to a namespace.

Sorry, bunged this one up. I meant:

   def startElement(self, name, attrs):
       if name[0] == xslt_ns:
           # do something useful

The calling convention for this is the same as my next option:

> > or:
> >   def startElement(self, ((URI, name), prefix), attrs):
> >       if URI != 'DAV:'
> >           return
> >       # do something useful
> 
> That is an option.
> 
> > Both of your alternatives constructed a tuple at *runtime*. I'd rather avoid
> > the tuple construction and keep the (IMO) cleaner model.
> 
> How can you avoid constructing a tuple at runtime? We can't construct
> them before the program starts!!!

Sure you can :-)

xslt_ns = (whatever_uri, whatever_name)
...
    def startElement(...):
        ... xslt_ns ...

The tuple is constructed at import time.

If those whatever_* values are strings, then it is even possible to marshal
a tuple constant into the .pyc file (via peephole optimization). With the
stored constant, then you even avoid the tuple construction at import time!
[ yah yah, nobody cares about saving a few cycles at import time, but it is
  a neat effect :-) ]

> > > Namespaces are complicated and nasty. The old SAX API did not change
> > > that.
> > 
> > They don't have to be. I've never had a problem with them in my qp_xml
> > module or the users of that module.
> 
> Namespace are nasty long before you get to an API. You don't even need
> to be sitting at a computer. Just read the spec! By the way, qp_xml's
> handling of the xml: namespace is incorrect.

In what way? Please specify.

I suspect that your thinking here is simply that a spec does not (yet) exist
for the qp_xml API. Specifically, it issues namespace/localname tuple pairs:

  ('DAV:', 'response')

When you have no namespace, you get:

  ('', 'some-element')

When the xml: prefix is found, it returns:

  ('', 'xml:foobar')

This is done because qp_xml does not preserve prefixes. Thus, an application
is required to manufacture prefixes when dumping the QP tree back out. The
particular tuple format for xml: prefix does two things:
1) '' signifies no namespace, so a prefix is not generated for the name
2) 'xml:' in the elem name ensure that the xml: prefix gets dumped out

If we returned the data in another way, the application might accidentally
replace the prefix with something other than xml:.

Final note on the QP name values: since '' is used to signify *NO*
namespace, it is important to note how defaults are handled. QP will always
resolve defaults before returning values. When re-generating content,
default namespaces should not be used, unless you really know what you're
doing w.r.t. the no-namespace signifier and the xml: prefix.


Cheers,
-g

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