From: Evan Lenz (elenz@xyzfind.com)
Date: Thu Dec 06 2001 - 03:44:22 CET
Jim Fuller wrote:
>
> Evan Lenz wrote:
> > Actually, I don't see why XSLT processors couldn't optimize the
collection
> > represented by the "input" parameter. The XSLT Rec says: "XSLT does not
> > define the mechanism by which parameters are passed to the
stylesheet."[1]
>
>
> this is indirectly causing some serious interoperability problems between
> implementations.i would like to see Transquery avoid this silliness.
The way to avoid it is to specify exactly what the particular parameter's
name means and, secondarily, to suggest implementation approaches for
various processing models. In terms of interoperability, there's nothing
intrinsically problematic about using xsl:param for this purpose, especially
in comparison to using an extension element or function. The very nature of
the TransQuery input idea is to leave construction of the input collection
*outside* the scope of what the stylesheet writer sees, just as construction
of the source tree is outside the scope of what the stylesheet writer sees.
xsl:param provides the needed finger into the outside world.
You're not going to get around the interoperability problem of
parameter-binding (or source tree construction, for that matter), unless you
require all XSLT implementations to use the same processing model, same
programming language, etc. This problem is unavoidable. A monolithic
solution is not what's needed. Rather, different processing models will
require different implementations. Ultimately, that's not the TransQuery
spec's concern, unless only in an appendix for suggested approaches to
implementation. If JAXP/TRAX wants to model XPath types (node-set, boolean,
string, number) as Java interfaces (which would enable binding to the
TransQuery input parameter in a non-processor-specific way), then that's its
perogative. If the XML:DB API wants to specify a TransQuery driver, then
that's its perogative. If an XML database vendor wants to always bind the
input parameter to a node-set corresponding to the union of all stored
documents, then that's its perogative.
For command-line XSLT processors, we might suggest in an appendix that users
simply implement the TransQuery parameter-binding themselves in XSLT itself
(via an importing stylesheet wrapper that overrides $tq:input, binding its
value to a node-set returned by the document() function) and defining the
input collection in a special manifest document. Then, instead of typing
this:
$ saxon myQuery.xsl someSourceDocument.xml
They would type this:
$ saxon generateWrapper.xsl any.xml query=myQuery.xsl \
manifest=input-uris.xml >myQueryWrapper.xsl
$ saxon myQueryWrapper.xsl someSourceDocument.xml
In fact, they could put this in a script such as "saxon-transquery" and
always type this instead:
$ saxon-transquery myQuery.xsl someSourceDocument.xml
The input document collection would always be available, whether used or
not. There would be some overhead involved in the additional transformation,
but at least you would have a complete TransQuery implementation.
This little exercise brings home the point that TransQuery doesn't add any
functionality to XSLT. Rather it provides a simple contract between XSLT
authors and XSLT processing models--an agreement that tq:input refers to a
node-set of zero or more root nodes.
Evan Lenz
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET