Sorry for commenting on a couple of letters at once:
1) Caching. I think the "blind" approach won't do because the trees tend
to be just too big for this. Jamie and Honza say it would suffice to
give the caller the option of passing/getting a tree instead of
serialized text, and leave the caching up to him (her).
This does NOT require publishing the Tree object which would be bad
indeed. The caller doesn't need to access the trees directly, so passing
a void* (and casting it to Tree* in Sablotron) would do. On the other
hand, the internal cache gives better control: in case the caller passes
a bad handle, we could report an error rather than crash. Does this
advantage pay off?
2) Extra URI scheme. Say there's a URI scheme 'parsed:' for access to
the pre-parsed trees. A disadvantage of this is that it can hardly be
used inside a stylesheet (in a <xsl:include> or document()). Note that
these includes are arguably among the main candidates for parsing.
3) IDEA. What about the following? Let's say Sablotron does keep a cache
itself, but the user says explicitly what to put in and when to dispose
of something. (So it's not much of a cache really.) This works fine with
the includes and does not waste memory on unnecessary trees. The API
functions for this needn't be as complicated as Honza suggests. You
could for instance pass a list of URIs to be cached. If the result URI
is on the list, no serialization is done and you can simply pass the URI
on the next call to Sablotron which will find it in the cache.
A more sophisticated function might still let you say "cache all the
includes" or "cache everything" - if you need.
One issue to be addressed is caching the named buffers
('arg:something'). Here, the URI is sort of temporary (the same URI may
refer to something completely different on the next call) which can
introduce conflicts between the contents of the cache and the input from
the caller. Do you get my meaning?
4) Steve's extensions. In what way would you define the extension? Would
it be OK to pass any tag in a particular namespace, with attributes, to
a handler you register? That would be easy. Passing the subtree is
obviously harder.
Tom
