From: Evan Lenz (elenz@xyzfind.com)
Date: Tue Dec 11 2001 - 08:52:36 CET
Chris Bayes wrote:
> Ok that works because you have a root node tq:tq all is fine. I guess
> that I am not precluded from doing that? Now to fit in with the spec(?)
> I need to provide a node-set as the tq:input param. So one would think
> that...
<snip/>
> I solved it in transquery.js but then it occurred to me why
> not have a root element <tq:tq ? I don't think that it would add much to
> the spec and it could carry a bunch of attributes that might be useful.
I think you're suggesting that the input documents all be embedded directly
within a single master input document. This is actually very different from
the $tq:input idea. It was the way I originally thought that XSLT could be
used as a "query language", i.e. by treating a collection of documents as
one logical source tree and drilling down from the root of that master tree.
There are problems with this approach. For one thing, the id() function
stops working, because you've transformed the identity of the original tree
and ID clashes become possible. Also, base URIs of nodes may change if
they're now a part of a different document than the original. If XSLT didn't
give us a native way of accessing multiple documents, then this would
probably be the only way we could query multiple documents, i.e. by defining
a processing model that views multiple documents as one document input to
the stylesheet. But, happily, XSLT does give us a native way of dealing with
multiple documents, so we can query them without breaking id() or document()
(for relative URI resolution) and while being able to maintain the
boundaries between documents along with continued support for document
fragments.
I agree with you that metadata can be useful. That's why the meta-document
convention can be a useful alternative or supplement to the TransQuery input
parameter, when metadata is important.
> Also wanting to avoid
> feature bloat I don't want to advocate much more than the simple param
> passing mechanism but what about a small simple schema describing the
> structure of the input database. Maybe it is too much I don't know maybe
> it should describe branches and leaves or tables and columns instead of
> folders and files.
I think that a small schema for describing the value of the TransQuery input
parameter is a good idea. This would be appropriate for command-line
processors and other non-database processing models. I also still think this
would best go in a non-normative appendix of the TransQuery spec. And it
should only describe the information that is necessary to populate the
TransQuery input parameter, which basically is nothing more than a set of
URIs, no?
For example:
<input-uris xmlns="http://www.xmlportfolio.com/transquery">
<document href="foo.xml"/>
<document href="bar.xml"/>
<document href="http://www.example.com/bat.xml"/>
</input-uris>
I don't think the schema needs to (or should) describe any other information
than a set of URIs.
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET