[wsf-c-dev] AXIOM NG

[James Clark]

On Sun, 2006-12-10 at 07:26 +0700, James Clark wrote:
> > Are you basically suggesting that the entire system be implemented in a 
> > raw pull API?
> 
> Not really. See my first message on this:
> 
>   http://www.wso2.org/mailarchive/wsf-c-dev/2006-December/000047.html

Let me add a few additional observations.

1. There are three interfaces, which are all essential.

- xml_reader deals with reading
- xml_writer deals with writing
- xml_element deals with storage

Crucially, xml_element is orthogonal to xml_reader and xml_writer: it
doesn't provide XML reading/writing functionality, which would overlap
with xml_reader and xml_writer.  Instead you use an xml_reader to read
an xml_element and xml_writer to write an xml_element. You always read
XML in the same way, using an xml_reader, regardless of whether or not
it has been stored.

2. The key thing that determines how efficiently you store XML is
whether you need to use it multiple times or just once: if you use it
just once, then you can stream it.  The storage interface (xml_element)
exposes this using ideas inspired by linear logic (see
http://en.wikipedia.org/wiki/Linear_logic and
http://home.pipeline.com/~hbaker1/Use1Var.html).  In contrast to linear
logic and linear type systems, here the linearity of an object is
dynamic. This allows the system to transparently and opportunistically
stream whenever it's possible to do.

3. The xml_element is very limited compared to the random-access
DOM-like API provided by AXIOM currently.  This greatly increases the
possibilities for efficient implementation, while providing sufficient
capability for almost all things that a SOAP engine needs to do.  There
will be rare cases where it would be convenient to have a full
random-access (probably read-only is enough) DOM-like interface.  I'm
thinking particularly of XPath in XML Security: most cases can be
handled by a streaming XPath-subset implementation, but to do a 100%
job, it will occasionally be necessary to build a tree.  It should be
rare enough that it's not a performance issue. For this, we can either
fallback to libxml2 or do our own XPath-based tree and associated XPath
implementation.  To start with, reusing libxml2 makes the most sense to
me.  (I would also use libxml2 for parsing of XML with DOCTYPE
declarations, so our specialized parser isn't slowed down by having deal
with entities, default attributes and other such XML cruft.)

4. xml_reader will also need async support, which is absent from the
pull APIs I've seen.  More on this later.

James