From: Evan Lenz (elenz@xyzfind.com)
Date: Sun Jan 20 2002 - 09:34:00 CET
Hi Jim,
Thanks for your helpful suggestions.
> a) update FAQ ( point 7 ) to reflect CB's javascript implementation ( if
> that is ok with him )
Done. http://www.xmlportfolio.com/transquery/faq/#implementations
> b) i particularly liked this snippet/characterisation by EL;
>
> '.......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've added a little text to question #1 of the FAQ along these lines.
http://www.xmlportfolio.com/transquery/faq/#whatis
> maybe something for the FAQ ( point 1), in addition i think that a common
> scenario i.e. that of a collection of xml documents held in a
> file/directory
> is a good illustration ( as that done by CB's jscript implementation ).
I didn't get this far, but this is certainly one of the processing models
that we'll want to include in some kind of list.
> I think smaller, tighter, well
> defined family of mini specs that have low cohesion but greater
> interoperability opportunities ( say that 3 times fast ) may offer better
> architecture.
I think I agree with your assessment. TransQuery input should not be
dependent on (a much more involved) update mechanism.
> I think that the existance of a simple update mechanism will 'overshadow'
> the original Transquery mission, which ( correct me if i am wrong ) is to
> allow 3rd party software writers to give output hooks from their software,
> in tactical situations, for xslt authors to have fun with and go query mad
> ( yikes i think i have to make a limerick ).
>
> 'I want to grep with XSLT
> like i did on FreeBSD
> and get my data back
> in pointy bracketseeess'
The grep analogy is nice, but with XSLT it's hard to imagine a truly
scalable implementation that's not based on some kind of persistent data
model (e.g. an "XML database"). Even so, TransQuery input can still be
useful in contexts that don't need to scale up very far.
> and another point what about conforming to some sort of schema, dtd, or
> whatnot when updating information ( and the possible implications of data
> types ), arghhh.
I would think this is out of scope for TransQuery, but in scope for XQuery.
That's a big problem to try to solve. TransQuery is not that ambitious :-)
> i think that update should be dropped or dealt with in completely
> different
> yet related spec, as the scope is much larger then Transquery.
This input is valuable. It may be a good idea to exclude update from an
initial TC charter (and deliverable). I wouldn't mind if this turned out to
be the smallest OASIS spec (or the shortest-living OASIS TC) yet.
> d) in the spirit of seperate spec, i like the database layer that CB was
> suggesting, and possibly having a list of the document collection returned
> as tq:document ( yes i think this was introduced also as something to do
> with an update mechanism, forget about that for the moment ).
> this has a lot
> of useful potential... will expand a little later on this though
Looking forward to your future expansions on these ideas.
Evan
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET