From: cutlass (cutlass@secure0.com)
Date: Thu Jan 10 2002 - 19:33:57 CET
geez, u people dont take vacations >?
some random points
a) update FAQ ( point 7 ) to reflect CB's javascript implementation ( if
that is ok with him )
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.'
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 ).
c) re use of XSLT as an update: I think that what could occur here is a
family of small specifications; one of them being Transquery, a possible
TransUpdate, and so on ....; the reasoning for this is that a 3rd party
implementator can create what additions they want and be conformant to that
particular part of the puzzle. A load of specs seem to go overboard (
aforementioned feature creep and design by commitee probs... ), and address
endless complexity by determining a 'core' and advanced features ( i think
this is done with XForms for example ). 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 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'
( i couldnt resist )
an update mechanism would at its simplest require to 'replace' or 'update'
external data; does it matter to the XSLT author which document in a
collection they are updating ? maybe, maybe not. I would suggest
circumventing any problems this introduces by saying that any single
document could be directly worked on as a 'collection', but in the
Transquery sort of way of thinking its up to the the external interface to
determine this.... not the XSLT author to choose, which may seem limiting.
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 think that update should be dropped or dealt with in completely different
yet related spec, as the scope is much larger then Transquery.
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
cheers, jim fuller
This archive was generated by hypermail 2.1.4 : Fri Feb 22 2002 - 11:35:58 CET