On 28 Nov 2013, at 19:48, Adam Retter
<adam(_dot_)retter(_at_)googlemail(_dot_)com> wrote:
That is great news :-)
If you are inclined to share them, I would love to hear more about the
process and what your thoughts were when you were evaluating LLVM and
why you went with JET?
I'll ask O'Neil to share some of the experiences: he has led this development.
We did try more than one approach; rather than a formal evaluation it was more
a case of "if X doesn't work let's try Y", until we hit on Jet which did the
business.
So we need to create a libxslt2 bridge now right?
You mean in terms of bridging the API? We haven't really explored what's
feasible yet in terms of libxslt2 and libxml cooexistence. At the moment if
you've got data in a libxml tree you have to serialize and reparse to get it
into Saxon. I don't know if we'll ever be able to do better than that; I
suspect the overheads of doing it this way are lower than the overheads of
accessing the libXML tree node-by-node from the Java environment, but we'll
find out in due course.
From a first glance, the libxslt2 API is very closely coupled with libxml,
which makes it difficult to reproduce directly; in addition, my experience is
that an API designed for XSLT 1.0 doesn't easily scale outwards to handle
XPath 2.0/3.0, XSLT 2.0/3.0, XQuery 3.0, and XSD 1.1, plus pipelines mixing
all of the above.
Michael Kay
Saxonica
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--