> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> Unlike Jose Alberto, I think it's a 'good' thing than
> referencing an declared attribute of a <macrodef> in its
> body/impl resembles the XSLT referencing of a attribute of
> the current XML element!
>
> The similarities are striking, and the syntax is well known
> and clearly documented. The <macrodef> attribute *will* be an
> XML element attribute when it's used actually!!!
>
Well just remember that in XSLT we are talking about XPATH.
The actual parameters here are "@x" (an attribute) or "$x"
(a variable) or "x" an element. The "{}" is just syntax sugar
so you can write expressions easily inside XSLT attribute values.
In XSLT you can write:
<myelement param="{concat(@name, '=', @value)}"/>
which results in the concatenation of the three values.
But you can also write that more verbose:
<myelement>
<xsl:attribute name="param">
<xsl:value-of select="concat(@name, '=', @value)"/>
</xsl:attribute>
</myelement>
XSLT has a very specific syntax for variable/attribute names.
> The point is not to resemble the existing notation for
> dereferencing Ant properties, since that's what it's supposed
> to be distinct from, which is why @{x} feels wrong to me (and
> looks ugly IMHO ;-).
>
> The point is to use a widely used notation for a widely
> similar purpose, i.e. the XSLT notation, which as I noted
> above is so similar to the semantic of what's being done.
Your proposal selection is not XPATH nor the XSLT expression language,
yes it has some simillarities, but on the other hand that may add to
confusion.
Jose Alberto
PS: my current choice is "@{x}" before was "$(x)", hummmmm
maybe should pick "@(x)" hummmmmm, oh well, somebody, just pick
something!!!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
