[XML-SIG] Roadmap document - finally!
Tue, 20 Feb 2001 08:47:59 -0700
> Lars Marius Garshol <email@example.com> 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 exposes *just* the infoset in the simplest possible way
> (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
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.
How is the memory footprint?
Uche Ogbuji Principal Consultant
firstname.lastname@example.org +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