From: cutlass (cutlass@secure0.com)
Date: Thu Dec 06 2001 - 11:46:58 CET
Hello Evan,
----- Original Message -----
From: "Evan Lenz" <elenz@xyzfind.com>
> 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
i agree
> in comparison to using an extension element or function. The very nature
of
yes again,
> 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.
agree
>
> 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
yes,
i understand completely the difficulties of parameter binding, but that
doesnt stop me from discussing the topic over and over again...hehe.
i quess the point i was making is that there is somewhat of a common data
querying and processing model emerging along the lines of a native xml
database that exposes this data via port 80 a common interface using xpath
to query.....and returns well formed xml upon receipt of the XPATH.
i like this as i can aggregate all my data under a one-stop shop,
xml/odbc/text/etc; there are many benefits to this that are outside the
scope of this list.
so in terms of scope and problem domain if its relatively small ( think the
result of grep xml analogy ) then a parameter $tq:input is great, for larger
frameworks i would like to see a standard mechanism of including the
Transquery contract within the native xml database situation..... i am
thinking of yet another best practice for this situation.
> 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.
yes i agree, i my thinking was a bit adled.
> 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 is yet another best practice as i see it.
> 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.
i actually think this little exercise has also generated some clearer
language, ie this paragraph should have a home somewhere either in the FAQ
or the spec itself.
cheers, jim
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET