OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XQuery -- Reinventing the Wheel?



Does the XSLT spec require that all templates are known apriori? I know that
all (or most?) current implementations do, but as an old prolog/datalog
programmer, I would prefer if I can dynamically add and delete rules for
adhoc querying. If that is not possible, then this is rather limiting and
would take value away from the data-driven processing model in the context
of querying. It would more or less require to reinclude all already defined
rules...

I am certainly not against keeping template rules in XSLT (I find them great
to do document transformation), but I don't think I want to add them to
XQuery right now...

Best regards
Michael

> -----Original Message-----
> From: Evan Lenz [mailto:elenz@xyzfind.com]
> Sent: Sunday, February 25, 2001 1:56 AM
> To: Michael Rys
> Cc: xml-dev@lists.xml.org
> Subject: RE: XQuery -- Reinventing the Wheel?
> 
> 
> On Sat, 24 Feb 2001, Michael Rys wrote:
> 
> > It is true that if you have full recursion, that you can 
> express the same
> > queries as with templates. The difference from an 
> optimization point of view
> > are as follows, IMHO:
> > 
> > 1. Making the recursive processing explicit, the rule-base 
> is hardcoded into
> > the code. Thus, a compiler can do static analysis and 
> optimizations. This is
> > only partially true for template processing, mainly when 
> your rule-base is
> > not changing (which is the case for single XSLT template 
> files, but probably
> > not anymore for query systems based on template processing).
> 
> Huh? XSLT's processing model is such that all template rules, 
> patterns,
> and expressions are known at compile-time. They *cannot* change, so
> nothing about them detracts from the processor's ability to do static
> analysis and optimizations. There's nothing less static about implicit
> recursion than explicit recursion.
> 
> > 
> > 2. Since the explicit recursive processing is normally only 
> used when no
> > other mean is necessary, people will more likely write 
> better optimizable
> > expressions.
> 
> This point is at least defensible. I just disagree. Note that 
> it's not a
> technical reason for keeping template rules out of the language, but a
> practical one. I would much prefer to address this issue by 
> warning people
> that using template rules may be slow (if that's in fact the 
> case), rather
> than taking away the ability to do so altogether.
> 
> Evan Lenz
> XYZFind Corp.
> 
>