From: Evan Lenz (elenz@xyzfind.com)
Date: Fri Dec 07 2001 - 07:20:52 CET
Jim Fuller wrote:
> 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.
Well, the XML:DB API specifically addresses part of the processing model for
XML databases. Perhaps what you want is an XML:DB interface;
TransQueryService applied to a Collection instead of XPathQueryService, for
example (to answer your question about what "Collection" I was referring
to).
http://www.xmldb.org/xapi/api/org/xmldb/api/modules/XPathQueryService.html
However, I would like native XML databases to be able to implement
TransQuery without necessarily being required to support the XML:DB API.
Moreover, for Java, JAXP already provides a halfway-decent API for XSLT
processing. I wouldn't want to reinvent that wheel. (However, as I alluded
to before, JAXP does need an interface corresponding to the XPath objects
(node-set, boolean, string, number), particularly node-set if TransQuery is
to be supported.)
I'm willing to hear more specifics of what you have in mind. Perhaps it's a
lot different than an API; I don't know. Let me ask you this: how important
do you think it would be for a native XML database to allow the user to bind
the TransQuery input parameter to different individual document collections
(as opposed to always accessing the entire database of documents)? The
TransQuery spec doesn't address this, but I have some feelings about 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.
Good to know. I think you're right. Dialogue is a good thing.
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET