Re: [xslt] ANN: TclXSLT 0.1alpha

[Steve Ball <Steve Ball zveno com>]

Daniel Veillard wrote:
> > An advantage of using this package is that the XSLT stylesheet
> > is cached after it has been compiled.  This makes subsequent
> 
>   Hum, that's relatively classic, what's your cache flushing
> algorithm ?

The package uses the Tcl object system (do not think OO here...).  
Tcl objects are dual-ported, with a string representation and 
an internal rep.  TclXSLT first sees the stylesheet as a string 
object, compiles it, and then sets the internal representation 
of the Tcl object to be the compiled stylesheet structure.

Tcl objects are reference counted, so when Tcl doesn't need the
object anymore it is freed.  Tcl takes care of that automatically.
Also, if the object is changed then the internal representation
is discarded and a function in the TclXSLT package is called to
free resources.

The impact of all this on an application is that everything is
mostly transparent.  The script must keep a reference to the object
in order to prevent it from being destroyed.  This is usually 
achieved by assigning it to a variable.

> Do you have a way to force a given precompiled
> stylesheet to be available ?

No.  If the application wanted to pre-compile a stylesheet then
it would have to perform a dummy transformation.

> > A new feature of this package is that XSLT extensions can be
> > implemented using Tcl.  At the moment this is limited to
> > the implementation of extension functions, passing strings
> > as arguments and returning a string value.  Future work will
> > extend this to extension elements and allow handling of nodes
> > and nodesets.  This general-purpose mechanism allows extensions
> > to be easily created, and registered/deregistered on-the-fly.
> 
>   Sound fun too. I didn't expected extensions to take off so fast.
> Maybe XSLT in itself is too limited.

I presented my thoughts on this subject at the recent O'Reilly
Open Source Convention, and I'll summarise them here:

Scripting languages give us flexibility in designing and implementing
software systems.  An engineer can choose between implementing
functionality at the system level, using languages such as C, C++
or Java, or at the scripting level (I won't go into the pros-and-cons 
of the various languages here).  Best practice is to implement
primitive functions in a systems programming language, and then
implement high-level application logic at the scripting level to
glue those prmitives together.  This gives the engineer a two-level 
approach to designing software.

What I now see happening is that XSLT is being layered over the
top of scripting languages in order to give us a third level.
XSLT is being used to implement high-level application logic,
and primitives for the stylesheet are implemented using a 
scripting language.  Best practice will be to minimise (or avoid
altogether) the use of extensions, but there are good reasons to 
employ extensions:  for dealing with unstructured data that might 
occur inside (badly designed) XML documents and real-world, external
systems (databases, processes, the filesystem, etc).

Hence I see a future where scripting languages play second-fiddle
to XSLT in software system architectures.  They're still important
(and so are C, C++, Java, etc), but the real focus will be on XSLT.

>   Can you provide an URL so I can add a link in the contrib section ?
> (actually I should add a Language wrapper section to the main page).

I don't have a URL for the TclXSLT package itself - yet.
For the moment, please link to the TclXML project:
http://tclxml.sf.net/

Cheers,
Steve Ball

-- 
Steve Ball            |   XSLT Standard Library   | Training & Seminars
Zveno Pty Ltd         |     Web Tcl Complete      |   XML XSL Schemas
http://www.zveno.com/ |      TclXML TclDOM        | Tcl, Web Development
Steve.Ball@zveno.com  +---------------------------+---------------------
Ph. +61 2 6242 4099   |   Mobile (0413) 594 462   | Fax +61 2 6242 4099