[XML-SIG] SAX Namespaces

Paul Prescod paul@prescod.net
Mon, 03 Jul 2000 21:08:39 -0500


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 rawname is
> actually quite hard to use. We had talked about preserving the namespace
> *prefix*. The third item in the provided data should be the bare prefix.

Arguable. I could go either way on that issue. The parser has both the
prefix and the rawname hanging around. The existing code said "rawname"
so I left "rawname". SAX/Java also uses rawname.

> > #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.

> To enable comparisions like above, the best output format would be something
> like: ((URI, element-name), prefix). This enables people to use name[0] for
> the distinguished name (primary key).

I could live with it, but it's another level of tuple-building and
ripping apart. You are assuming a particular use mode now. I'm trying to
hand the three parts to the user or application and let them do with
them what they want.

> > SAX is pretty painful for this sort of thing and I would like
> > to see people move to something with a stack and tree mode (whether
> > pulldom, Pyxie, whatever) soon.
> 
> Don't tell me, or others, where to move our code, our designs, or our
> algorithms. It is not your place to legislate.

If you don't decide what your API is for, you can't design it. You make
certain assumptions about how people will being doing name comparisons
with this particular API and I make other ones.

> 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.

> 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!!!

> > 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.

> Not the rawname... the prefix. Combining the prefix/name means that somebody
> must then yank it bank apart to deal with that prefix. When they arrive
> seperate, then the developer has an easy choice for putting them back
> together.

Sure, but if the only reason you are going to ever use the prefix is to
glue it back on to the localname, then why bother separating it. What
use case do you see for wanting the prefix alone? I couldn't think of
very many. Wanting the whole rawname is more common and is what is
required by DOM and XPath and the various specs writting on top of them.

> In fact, I hope to
> > optimize the SAX layer away altogether. (by making PyExpat a SAX parser
> > and minidom et. al. SAX consumers).
>
> Please do not add SAX to the front of pyexpat.c. I always want to have
> access to the raw handlers. 

That's what I just said. Read again from "I hope to..." You'll note that
the SAX API I am describing is almost a renaming of PyExpat's API (when
PyExpat namespaces are turned off).

> Expat is known as the *fastest* non-validating
> parser around. I don't want to see a bunch of stuff gummed onto the Python
> version which kills that speed.

That's what we're talking about.

> You should not be making API changes unilaterally. That is totally against
> the spirit here. Great, you have commit access. I do, too. Should I go in
> and start making API changes because they suit me?

Chill out. I was given the job of putting SAX into Python 1.6 overnight
(literally!). This API change made it easier to get it into the beta.
One major virtue of the proposal is that the

def startElement( self, name, attrs ):
	...

signature is the same as SAX 1 which made integration with minidom and
other handlers easier in the time available. Pyexpat and minidom were
both expecting two argument handlers. Changing SAX was easier than
changing them. Both need to change before Python beta 2 anyhow so this
isn't a major issue anymore. I thought it was pretty cool that Python's
dynamic typing allowed us to go from a namespace-unaware to a
namespace-aware mode without inventing a new kind of handler. That's why
I posted about it on the weekend.

-- 
 Paul Prescod - Not encumbered by corporate consensus
The calculus and the rich body of mathematical analysis to which it 
gave rise made modern science possible, but it was the algorithm that 
made the modern world possible.
	- The Advent of the Algorithm (pending), by David Berlinski