Re: Why not reinvent the wheel?

[Jay Zhang <jz@intermicstech.com>]

Charles Reitzel wrote (Tuesday, February 27, 2001 11:13 AM):

...
> That leaves the syntax issue, which IMO, does not justify an entire,
> freestanding query standard.  It may well justify a non-XML front end to
> XSLT, however.  I'm sure, day-to-day, I'd prefer to use one.
> 
> I think this would be a good evolutionary strategy.  If XQuery is a front
> end to XSLT, there is nothing stopping the intermediate format from being
> optimized away, so to speak.  But the underlying engine is the same.
> Anybody remember cfront?
> 
...


XSLT and XQuery should not be two flavors of the same thing since 
there are two distinct roles that transformation mechnisms 
need to play. 

In applications context, there are two types of use-cases. One is 
to process a large document with relatively complex structure
and the other is to process a large number of records with 
relatively simple structure. Human beings seem to have difficulty
to handle simultaneous complexity on both dimensions.

IMO, XSLT is more or less designed with the first case in mind 
and XQuery is designed with the second case in mind. They
should go down the separate paths while facilitate and optimize 
accordingly. Of course, they share some foundational elements.
 
If they have similar expressive power today, they should look
very different in the future. The first case calls for
an elite group of "smart" programmers. The later case calls for
large number of "dumb" programmers. That is why I compare
XSLT/XQuery to Perl/SQL (without any disrespect to Perl). Each
group will develop totally different standard practice. In the
end, an average XSLT program should look very different from an
average XQuery program, even after superficial syntax mapping.

I am rooted for Jonathan in this constructive debate. However,
the possibility of optimization and expressive power is not the 
best arguement for the existence of XQuery. As a former compiler 
developer (I developed one of the leading ASN.1 compiler: the one 
in ASN.C/C++ suite) with an algorithm background, I am sure that 
any optimization done to XQuery at this stage could be 
transplanted for XSLT. The expressive power part is demonstrated
in the famous paper that started this thread.

I take the liberty to rephrase a position as: 

(1) XQuery is planned for specialized optimizations aiming at 
the second type of use-cases. XSLT should be optimized for 
navigation in ever more complex document structure.

(2) XQuery will evolve towards saving typing and thinking for 
average IT professionals in the second type of use-cases. XSLT 
will develop more expressive power to express ever more 
sophisticated pattern in a document.