"Joerg Heinicke" <[EMAIL PROTECTED]> wrote:
> Pier Fumagalli wrote:
>>
>> <ul>
>> #foreach {parameters}
>> <li>[EMAIL PROTECTED]: [EMAIL PROTECTED]</li>
>> #end
>> </ul>
>
> Having only read one article about XQuery with a few samples this *looks*
> like XQuery for me. But my knowledge is not deep of course :-)
>
>> [...]
>> XQuery [...] uses to many curly braces (and I go nuts) [...]
>> [...]
>
> Ah, here you come to XQuery. Too many braces? It's at least much shorter
> than the complete XML syntax of XSLT.
Indeed... But it uses curly braces a little bit too much, IMVHO. Curly
braces are used to separate character-data from template language, literally
escaping sections of code within an XML document. That is absolutely fine,
but it makes the final document less readable, IMVHO.
The other "disadvantage" I see about XQuery is the fact that at the end of
the day it is not a "templating" language. I really don't think that in a
template (a-la Velocity, I mean) you should have the "return" instruction.
"return" implies "call function", and therefore a programming language in
the back. Templates are not programming, all you can do is apply more
templates (therefore no whatsoever "return" statement).
That is the beauty of XSLT, IMVHO, the only problem I have with XSLT is its
utterly complex syntax.
>> <div>
>> #if {parameter/@name = "primary"}
>> <span class="red">
>> #elif {parameter/@name = "secondary"}
>> <span class="green">
>> #elif {parameter/@name = "tertiary"}
>> <span class="green">
>> #else
>> <span>
>> #end
>> [EMAIL PROTECTED]:</span> [EMAIL PROTECTED]
>> </div>
>
> Hmm, in my opinion it should at least be impossible to produce not
> well-formed XML. With the above I'm not satisfied ...
The production of non-well formed XML is impossible, the well-formedness of
the produced tree is checked (right now at runtime, but it can be done upon
parsing adding a little tree-validator.
The template, on the other hand, does allow constructs like the one above as
IMVHO, it simplifies to visually see what's going on and where. In my
opinion it is "visually" better to see the little template written above
than something like this:
<div>
<span>
#if {parameter/@name = "primary"} [EMAIL PROTECTED]"red"}
#elif {parameter/@name = "secondary"} [EMAIL PROTECTED]"green"}
#elif {parameter/@name = "tertiary"} [EMAIL PROTECTED]"blue"}
#end
[EMAIL PROTECTED]:
</span>
[EMAIL PROTECTED]
</div>
But I am positive that the second approach could be adopted as well (it's
either/or, not both), it would take just a little bit to write that
tree-validator I was talking about... Not a big deal.
Note that in any case, the document itself should not be an XML document
anyhow, as I might still want to do something like this:
#if {customer_type = "old"}
<invoice> .... </invoice>
#elif {customer_type = "new"}
<document type="invoice"> .... </document>
#else
#error {"Unsupported customer type"}
#end
And by even having something like this:
<template>
#if {customer_type = "old"}
<invoice> .... </invoice>
#elif {customer_type = "new"}
<document type="invoice"> .... </document>
#else
#error {"Unsupported customer type"}
#end
</template>
The complexity of handling the parsed characters intermixed with the
documents still requires building of a customized parser, IMO (which is
trivial using JavaCC - Slow but good).
(Skipped the rest as it outlines my shameful misknowledge of XSLT)
Pier
