From: Chris Bayes (chris@bayes.co.uk)
Date: Tue Dec 11 2001 - 13:28:43 CET
Evan,
The new version has 2 modes of working. The default is to use a meta
document and then the xslt document function and the other (-e option)
is to embed all files into one document. I see that the second mode is
not transquery but I was just playing with different methods of working.
I'll mail it to you and if there are no problems with it I'll stick it
up oin my site.
I agree on keeping things simple but things can be grouped and it is
easier to parse a tree in xslt than strings so what about
<input-uris xmlns="http://www.xmlportfolio.com/transquery">
<group path="">
<document href="foo.xml"/>
<document href="bar.xml"/>
</group>
<group path="http://www.example.com/">
<document href="http://www.example.com/bat.xml"/>
</group>
</input-uris>
But then maybe not.
Ciao Chris
XML/XSL Portal
http://www.bayes.co.uk/xml
> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xyzfind.com]
> Sent: 11 December 2001 07:53
> To: chris@bayes.co.uk; transquery-discuss@lists.oasis-open.org
> Subject: Re: [transquery-discuss] [ANN] transquery.js an
> implementation
>
>
> 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