[XML-SIG] Roadmap document - finally!

[Uche Ogbuji]

> Lars Marius Garshol <larsga@garshol.priv.no> writes:
> 
> > | A low-level Infoset API would be interesting
> > 
> > Personally I would prefer to see a nice tree-based XML API. My
> > personal opinion is that the DOM stinks and needs replacement.  Sean
> > McGrath's xTree looks far better, in my opinion.
> 
> Orchard[1] exposes *just* the infoset in the simplest possible way[2]
> (that is, an element's attributes is a mapping, contents are
> sequences, other attributes are simple values).
> 
> Orchard's nodes differ from DOM nodes in that they have no navigation
> methods or attributes (firstChild, nextSibling) or DOM-special
> manipulation (insertBefore, replaceChild) -- depending solely on
> Python's standard mapping and sequence interface.  Orchard also uses a
> (URI, LocalName) tuple for supporting XML Namespaces, instead of
> additional *NS methods.  Like Python's DOM binding, Orchard uses
> normal attribute accessors instead of (or in addition to) get/set
> methods.

Wow.  Sounds very clean and Pythonic.  I'll have to dig.


> "But Wait!!  That's not all!"  :-)
> 
> As a last note, the C optimization is well underway.  Orchard/Mostly-C
> is about 3-10x faster than pure Python/Perl while still retaining
> attribute accessors (with overrides), garbage collection, and no
> problems with cycles.  Current status is that we have a pure Python
> prototype of the Orchard APIs, and the Python binding is scheduled for
> early post-1.0 (as always, volunteers can change that!).  We have
> ported Matt Sergeant's XPath step evaluator to C as an example of C
> optimization for higher language modules[5].

How is the memory footprint?


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python