[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Saxon/C going forward

Subject: Re: Saxon/C going forward
From: "Tony Graham" <tgraham@xxxxxxxxxx>
Date: Thu, 19 Dec 2013 09:05:23 -0000 (GMT)
Re:  Saxon/C going forward
On Thu, December 19, 2013 3:31 am, Steve Ball wrote:
> Anyway, now that Saxonica has released Saxon/C Im 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

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


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


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


> * 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.


Tony Graham                                   tgraham@xxxxxxxxxx
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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.