Thanks for this useful data.
I'm a little sceptical about the virtues of being 90%, or even 99%, compatible
with another API. If you can't achieve 100%, you're going to create the
illusion that people don't need to worry about the differences and you're going
to get bug reports when people hit the 10% or 1% of cases where the behaviour
is different. We see this effect with JAXP: because the syntax of the interface
is the same, people complain when the behaviour is different, even though the
spec allows such differences.
So perhaps some kind of adapter or bridge module that translates common cases
might be a better approach than attempting to emulate libxslt2 interfaces
natively.
Michael Kay
Saxonica
On 29 Nov 2013, at 09:59, Tony Graham <tgraham(_at_)mentea(_dot_)net> wrote:
On Thu, November 28, 2013 8:32 pm, Michael Kay wrote:
...
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.
The top-level API for libxslt is at
http://www.xmlsoft.org/XSLT/html/libxslt-transform.html
The top level of the top-level API would be xsltApplyStylesheet [1]:
xmlDocPtr xsltApplyStylesheet (xsltStylesheetPtr style,
xmlDocPtr doc,
const char ** params)
xsltApplyStylesheetUser [2]:
xmlDocPtr xsltApplyStylesheetUser (xsltStylesheetPtr style,
xmlDocPtr doc,
const char ** params,
const char * output,
FILE * profile,
xsltRunStylesheet [3]:
int xsltRunStylesheet (xsltStylesheetPtr style,
xmlDocPtr doc,
const char ** params,
const char * output,
xmlSAXHandlerPtr SAX,
xmlOutputBufferPtr IObuf)
and xsltRunStylesheetUser [4]:
int xsltRunStylesheetUser (xsltStylesheetPtr style,
xmlDocPtr doc,
const char ** params,
const char * output,
xmlSAXHandlerPtr SAX,
xmlOutputBufferPtr IObuf,
FILE * profile,
xsltTransformContextPtr userCtxt)
A very unscientific search of code.ohloh.net showed these comparative
popularities in C code:
xsltApplyStylesheet [5]: 397,605
xsltApplyStylsheetUser [6]: 2,248,197
xsltRunStylesheet [7]: 1,113,553
xsltRunStylesheetUser [8]: 2,659,677
The two main ways to get a xsltStylesheetPtr would be
xsltParseStylesheetDoc [9] and xsltParseStylesheetFile [10], with
comparative popularities:
xsltParseStylesheetDoc [11]: 844,622
xsltParseStylesheetFile [12]: 4,330,439
By way of comparison, newXsltCompiler gets 7,274,828 hits in Java code [13].
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.
I don't think you could make a Saxon/C stylesheet look like a
xsltStylesheetPtr, but it does appear that most xsltStylesheetPtr are made
straight from a file or an existing xmlDoc, so I am back to my assertion
that you could get a long way by the XSLT processor just producing and
consuming xmlDoc even if, as you say, you have to reserialise from and to
the xmlDoc to get things to work.
Regards,
Tony Graham tgraham(_at_)mentea(_dot_)net
Consultant http://www.mentea.net
Mentea 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
XML, XSL-FO and XSLT consulting, training and programming
Chair, Print and Page Layout Community Group @ W3C
[1]
http://www.xmlsoft.org/XSLT/html/libxslt-transform.html#xsltApplyStylesheet
[2]
http://www.xmlsoft.org/XSLT/html/libxslt-transform.html#xsltApplyStylesheetUser
[3] http://www.xmlsoft.org/XSLT/html/libxslt-transform.html#xsltRunStylesheet
[4]
http://www.xmlsoft.org/XSLT/html/libxslt-transform.html#xsltRunStylesheetUser
[5]
http://code.ohloh.net/search?s=xsltApplyStylesheet&pp=0&fl=C&fe=c&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
[6]
http://code.ohloh.net/search?s=xsltApplyStylesheetUser&pp=0&fl=C&fe=c&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
[7]
http://code.ohloh.net/search?s=xsltRunStylesheet&pp=0&fl=C&fe=c&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
[8]
http://code.ohloh.net/search?s=xsltRunStylesheetUser&pp=0&fl=C&fe=c&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
[9]
http://www.xmlsoft.org/XSLT/html/libxslt-xsltInternals.html#xsltParseStylesheetDoc
[10]
http://www.xmlsoft.org/XSLT/html/libxslt-xsltInternals.html#xsltParseStylesheetFile
[11]
http://code.ohloh.net/search?s=xsltParseStylesheetDoc&pp=0&fl=C&fe=c&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
[12]
http://code.ohloh.net/search?s=xsltParseStylesheetFile&pp=0&fl=C&fe=c&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
[13]
http://code.ohloh.net/search?s=newXsltCompiler&pp=0&fl=Java&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true
--~------------------------------------------------------------------
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>
--~--
--~------------------------------------------------------------------
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>
--~--