From: Evan Lenz (elenz@xyzfind.com)
Date: Wed Dec 05 2001 - 17:32:20 CET
Jim Fuller wrote:
> this is a perfect analogy
>
> and i quess, in these days of bulky specs, that what one expects much more
> .....though the basic tenet is that XSLT is well proven to be a query
> language unto itself, realistically it may be an entry language as larger
> commercial data use may require some more firepower.
Yes, XQuery 1.0 and XSLT 2.0 will add a great deal of power over and above
what XSLT 1.0 provides. The advantage of XSLT 1.0 is that it's a
two-year-old Recommendation and it's in widespread use already.
> i think that Transquery
> basic requirement is valid and should be addressed.
Good to hear.
> i think that the spec or faq should have a best practice section, that
> includes the meta document example, instead of removing it.
I agree that this sort of thing can go on the TransQuery website, perhaps
under "best practices for using XSLT with multiple source documents". Since
this and other ideas would be potentially valuable to TransQuery users, then
there is a place for it. However, I don't think it should be part of an
OASIS TC's deliverable (or a spec). TransQuery might denote two things: 1)
the specification for a top-level parameter contract (a spec), and 2) a code
name for "XSLT as query language". I think #1 should be the OASIS TC
deliverable and #2 should not, but best practices, conventions, software,
and other resources can exist independently.
> another thought after reflection is that what Transquery may propose, on
the
> XSLT side of life, is a new element instead of plain vanilla <xsl:param/>
> with namespace:name. too late for xslt2.0 but something to chew on
> nonetheless.
>
>
> reasons why ?
> ---------------
>
> -XSLT processor vendors may want to internally optimise their handling of
> document collections, a new element would allow for this.
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]
Coupled with the fact that XSLT provides the ability to identify a parameter
with a QName, I think it would be perfectly reasonable and acceptable for
existing XSLT processors, which already provide their own parameter-binding
mechanisms, to add explicit support for TransQuery. There is no opportunity
for collision with other stylesheets, because the "input" parameter is in a
namespace. As I think about it more, why else except for something like
TransQuery would XSLT provide the ability to identify parameters with a
QName? (That's a rhetorical question.)
> -experience with the different methods of pumping in a param into xsl is
> causing some compatibility
> issues between different processors, and some rather sticky architecture
> decisions come out of this, maybe some indirection would be useful a
choice
> between param and document() ???? in the form of an attribute select ?
The OASIS TC members could address how the TransQuery input collection is
built in various processing models. However, I don't think that should be
part of the normative TransQuery deliverable. You could look at this like
"drivers" for TransQuery. For a database, you might want to just say that
the input collection consists of all stored documents (that's what decision
I made in the prototype software). For a database that implements the XML:DB
API, you might want to apply an XSLT query to a Collection of documents; the
input parameter could automatically contain the node-set corresponding to
that Collection. For a traditional XSLT processor that provides a mechanism
for loading documents from the filesystem (such as Saxon), you might want to
provide a simple format for describing a node-set to load in as the value of
the TransQuery input parameter.
For example:
input-uris.xml:
<input-uris>
<document href="foo.xml"/>
<document href="bar.xml"/>
</input-uris>
In fact, even without forcing the XSLT vendor to add explicit support for
TransQuery, you could alter your processing model so that instead of
directly calling your stylesheet query, you would call a wrapper stylesheet.
The following is a simple way to "implement" TransQuery using XSLT:
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:tq="http://www.xmlportfolio.com/transquery">
<!-- Augment your query by importing it into this one. -->
<xsl:import href="yourXSLTQuery.xsl"/>
<!-- Supply a value for $tq:input that is the node-set
described by the input-uris.xml file -->
<xsl:variable name="tq:input"
select="document(document('input-uris.xml')/input-uris/document/@href)"/>
</xsl:stylesheet>
> - future enforcement of digital signatures or encrypt/decrypt may
introduce
> some opportunities, as the Transquery processor may be the right layer to
> do apply credentials ?
>
> if i put my EXSLT hat on what one could propose is possibly a top level
> element;
>
> <xsl:stylesheet version="1.0"
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:tq="http://www.xmlportfolio.com/transquery"
> xmlns:exslt="http://exslt.org/"
> xmlns:transquery="http://exslt.org/transquery"
> >
> <transquery:input name="$tq:input" select="either document() or
$xslparam
> or no select element !"/>
>
> <xsl:template match="/">
> <xsl:copy-of select="$tq:input//purchaseOrder[paid='yes']"/>
> </xsl:template>
>
> </xsl:stylesheet>
>
> oh well, things get complicated, just some random thoughts.
I think the advantages of sticking with XSLT 1.0 (without extensions)
outweigh possible advantages of using an extension element.
Evan
[1] http://www.w3.org/TR/xslt#top-level-variables
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET