[XML-SIG] SAX Namespaces

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


On Thu, Jul 06, 2000 at 04:25:41PM -0400, Fred L. Drake, Jr. wrote:
>...
>  > Here is one way of looking at it. Let's say that there are four popular
>  > APIs out there:
> 
>   Ok:
> 
>         SAX     -- efficient version is sufficient
>         DOM     -- all my DOM code requests attributes by name, so
>                    lookup approach works; can be copied to a list on
>                    demand, or the efficient C AttributeList can
>                    provide this internally
>         Pyxie   -- not sure
>         QP_xml  -- exposes a dictionary interface, so something
>                    dict-like should work nicely as long as the
>                    interface & efficiency are right.

The efficiency is fine.

There are two options:

1) in C code, build a list of nested tuples
2) in C code, build a dict of tuple keys and tuple values

These are both about the same speed. Usability of the end result wins out
over any minor speed issue. It isn't even worth worrying about.

> 
>  > dictionary-structure directly. And even some subset of the 25% may find
>  > that the dictionary is sub-optimal because it is indexed based on the
>  > wrong property or properties.
> 
>   Again, I agree that this is an issue, and using a plain dict is not
> the right solution.  But methods that do name lookup make a lot of
> sense, while a list interface doesn't.

Agreed.

>   I don't think we really radically disagree; we just need an
> AttributeList implementation that meets the performance & sequence
> criteria.  Nothing that a little time & C code can't fix.  ;)
>   Should I persue that possibility, or am I missing something really
> substantial somewhere?  (Probably several things, but... related to
> this?)

qp_xml doesn't need an AttributeList implementation. That will just get in
the way. In fact, qp_xml will use *exactly* what is returned in the
callback. Maybe I'll strip the prefix out of the attr values, but probably
not.

Cheers,
-g

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