From: cutlass (cutlass@secure0.com)
Date: Wed Dec 05 2001 - 18:26:37 CET
Hello Evan,
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.
methods of passing xsl:param
------------------------------
- passing on URL: external handling of injection
- passing on cmdline: external handling of injection
- passing via scripting: internal handling of injection
> 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.)
>
I think this would be a desirable in terms of performance, though getting
the implementators to do this would rely on acceptance of Transquery.
And possibly initial optimisations may take the form of an extension
function bounded to the Transquery namespace.... instead of being builtin to
the Transquery processor.
though i am now thinking ( and correct me if i am wrong !) that typical
external data applications would have a Transquery plugin, which gives a
standard gateway into core XSLT 1.0.
would not the input need to be validated ? be a node-set ? before being
injected as a param etc etc.. which makes the plugin something a bit larger
and becoming a processor; which i think is being proposed now.
> 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.
could u define, many apologies, your use of the term Collection ?
> I think the advantages of sticking with XSLT 1.0 (without extensions)
> outweigh possible advantages of using an extension element.
if i refer to Transquery spec Introduction;
'It is the purpose of TransQuery to reconcile and harmonize the
single-source view with a multiple-source view, using existing standard
constructs in XSLT 1.0.'
want this be much much easier with XSLT / XPATH 2.0 ?
I do not agree that there are many advantages with sticking with XSLT 1.0 if
there was a choice between XSLT / XPATH 2.0. I want to take full advantage
of the version attribute.....
i consider XSLT 1.0 vastly underpowered, and flawed in only that XSLT is
growing far beyond its original intentions; though isnt this the case with
every 'useful' language. especially if i am building new libraries and
taking advantage of XPATH schema datatypes and finally using
relaxng/schematron validator with schema...etc etc in fact i am certain that
when XSLT2.0 is out that after 6mth that David Carlise will refer to XSLT
1.0 as 'the language known as XSLT 1.0 ', though i admit i may be wrong and
will buy pints at the next XSLT conference ( i think i bought the pints last
time ).
but thats not the point in this conversation, i agree that Transquery does
not require an extension element, but XSLT probably requires a normative
reference to the injection of the parameters at some point,
in my existing applications xsl:param and document() fight for supremacy,
essentially they follow their roles in that param normally holds session
data or selection vars whilst document brings in data for querying purposes,
but i can see when native xml database becomes ubiqitous ( or not.... ) that
i would have session data stored within the native xml database, which is
essentially what i am doing now as all my data, session data, and selection
vars come from xml datastore i.e. which puts it under a uniform ACL,
encryption, optimisation.... which means that your best practice option will
probably have greater adoption then the normative Transquery input.
i think that this is a very interesting effort, and if the processing model
is simple will experience high adoption in external applications... so i
just want to throw it around a little bit first.
chow, jim fuller
>
> 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