xsl-list
[Top] [All Lists]

Re: [xsl] Saxon/C going forward

2013-12-19 03:05:40
On Thu, December 19, 2013 3:31 am, Steve Ball wrote:
...
Anyway, now that Saxonica has released Saxon/C I?m working on a Tcl
interface for it. My requirements are as follows:

And my comments relate mostly to the no-longer-with-us Xacerbate all-XSLT
server:

* be able to parse an XML document and hold it as an object in memory; XML
documents do not necessarily come from files.

+1.  Which is why I go on about the easy path for replacing libxslt in
existing code is if the replacement can produce and consume libxml2 trees
(even if, as Mike Kay stated previously, it's done by reserialising and
reparsing the tree behind the scenes), but I still suspect most uses are
just straight parsing and processing of files.

* be able to compile an XSL stylesheet

+1.  Load it once and run it many times.

* be able to apply a compiled XSL stylesheet to an XML document and hold
the (primary) result as an object in memory; I also need to know what type
of document has been produced (XML, HTML, text, other); ditto for
secondary result documents

+1

* be able to pass parameters to the stylesheet; libxslt allows parameters
to be strings or XPath expressions

Goes without saying.

* be able to serialise an XML document

+1

* be able to implement extension elements and functions in Tcl (I call
that the ?Tcl sandwich? - XSLT sandwiched between the Tcl application and
Tcl extensions); btw implementing extension functions in libxslt is easy
but extension elements was much harder

I wrote mine in C.

* be able to handle exceptions and messages

+1

* be able to intercept external communications, such as document(),
unparsed-text(), unparsed-text-available(), xsl:result-document, etc

+1.  I had to override libxslt's xsltDocLoaderFunc to implement a document
cache (see Steve's first point).  Xacerbate didn't write secondary
documents, but didn't need to since the results of the transformations
were instructions to the 'virtual machine', and each result could produce
multiple new or replacement documents and/or make partial updates to any
existing document.

Breaking down the stylesheet execution into parts that can be performed
beforehand and kept ready-to-go is highly desirable. I mention compilation
above. If it were also possible to compute keys separately (for a
particular document) then that would be advantageous too.

Didn't have the keys requirement.

I wouldn't suggest that you set out to support Xacerbate, merely that it's
indicative of what programs can get up to once they advance past the
parse-transform-save level of processing.

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



--~------------------------------------------------------------------
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>
--~--

<Prev in Thread] Current Thread [Next in Thread>