[XML-SIG] SAX Namespaces

[Greg Stein]

On Thu, Jul 06, 2000 at 11:04:00AM -0500, Paul Prescod wrote:
> Greg Stein wrote:
> > 
> >   iv)  {(URI, localname) : (qname, value), ...}
> > 
> > Using (iv) means that the passed attribute dictionary is immediately usable.
> > The other forms require some initial processing, yet provide no value-add.
> 
> It is immediately usable as a dictionary, but it must be converted to a
> list for apps that want to iterate over attributes.

Oh, no. An app must say dict.items(). No biggy for that app.

> Examples include
> canonizers, tree builders, pretty printers and so forth. Here's the
> first line of qp_xml dealing with attributes:
> 
> >    for name, value in attrs.items():
> 
> Minidom uses the same first line, and so do a bunch of our other sample
> programs.

That is an improper basis for your claim. I do the .items() because qp_xml
does the namespace processing itself. If Expat does the processing, then I
would no longer need a lot of the work in qp_xml.Parser.start. And I
certainly would never do the .items() any more.

It is easy to transform a dictionary to a list. The other direction is much
harder.

> Here are my reasons for preferring a list to a dictionary, from most
> important to least:
> 
> 1. Many (most?) apps turn the dictionary into a list immediately.
> 
> 2. Those that want "lookup" capability might want (URI,name)-based
> lookup,  qname-based lookup, or both. The AttributesList interface
> provided both.

How could anybody do a lookup based on a qname? There is no way to know the
prefix. If you're talking about the "xml:" prefix, then you also know the
URI, so the lookup on a (URI, name) is a cakewalk.

> 3. Dictionary building and populating is more expensive than list
> building.

Eh? How is that?

And we are talking mostly about convenience for the Python programmer here.
Shaving a few cycles of C code is moot w.r.t. what the Python result is.

> 4. Attribute lists are typically so small (two or three items) that it
> is debatable whether a hashtable is the right index structure for them
> anyhow. Maybe linear search is better for a lot of apps. Maybe "lazy"
> indexing is better. I'd rather leave it up to the app.

The app can use either input. This is a no-op.

> 5. Pyexpat delivers the attributes as a list. Python 1.7 might just wrap
> the pyexpat data structure as a sequence rather than copying the
> attributes out (admittedly, more research is needed...!)

We're talking about delivering the right semantic to the Python user. Expat
doesn't have dictionaries, so it must deliver them that way. We are under no
requirement to match it exactly.

> 6. Bundling the qname with the value is not that intuitive.

It should be the prefix, not the qname. But yes: it isn't as intuitive as it
could be. But the (URI, name) key is definitely intuitive. It also stresses
the simple fact that you can only have one key/value for a particular
attribute. The semantics are a much better match.

Cheers,
-g

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