[XSLT] Is this a bug ( in the spec / in the tool ) ?

[Philippe Poulard]

Hi,

I need to define inside my stylesheet some xml structured datas, like
this (this example works) :

<xsl:styleshe et xmlns:xsl="http ://www.w3.org/1999/XSL/Transform"
version="1.0"
xmlns:data="*** Datas ***"
exclude-result-prefixes="data" >

<data:foo bar="data"/>

<xsl:template match="/">
<!-- XSLT stuff here -->
<xsl:template >

</xsl:stylesheet>

unfortunately, the content of my data structure contains values with
brackets and dollars, like this :

<data:foo bar="{$data}"/>

when i create the template, i catch the following exception :
javax.xml.trans form.Transforme rException:
org.apache.xml. utils.WrappedRu ntimeException: Could not find variable
with the name of data

because the xslt unmarshaler think that it is an attribute value
template; however, it is not, because present outside any context
handable by some xslt features such as output production or variable
computation; it is only valid xml data, and i want to retrieve this data
as it is written !

it is not clear in the spec that such a particular case should not be
evaluate as an AVT (if anybody knows, tell me)
i don't think it have to, because this part of the document is not for
the xslt processor, and can't be handled by it (i think); escaping with
{{ and }} has sense only for real AVT and would corrupt my datas, so it
is not acceptable

the only way to avoid this is to declare a variable of that name in the
scope of the data, like this :

<xsl:variable name="data"/>
<data:foo bar="{$data}"/>

baaah ! i don't want to declare false variables for my thousand datas :(
i really think it's a bug

do you think there is a lack in the spec ?
do you think this is a bug in apache ?
--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------

[Richard Tobin]

In article <bq**********@n ews-sop.inria.fr>,
Philippe Poulard <Ph************ ****@SPAMsophia .inria.fr> wrote:

<data:foo bar="{$data}"/>

The processor is right to interpret this as an attribute value
template; indeed the spec gives it as an example: "such as an
attribute of a literal result element". It's just the sort of thing
that attribute value templates are meant for.

You could write it as <data:foo bar="{'{$data}' }"/>

-- Richard
--
Spam filter: to mail me from a .com/.net site, put my surname in the headers.

FreeBSD rules!

[Philippe Poulard]

Richard Tobin wrote:

In article <bq**********@n ews-sop.inria.fr>,
Philippe Poulard <Ph************ ****@SPAMsophia .inria.fr> wrote:

<data:foo bar="{$data}"/>

The processor is right to interpret this as an attribute value
template; indeed the spec gives it as an example: "such as an
attribute of a literal result element". It's just the sort of thing
that attribute value templates are meant for.

You could write it as <data:foo bar="{'{$data}' }"/>

-- Richard

the example i described before is erroneous (in fact, there is a little
difference with the real case i encountered); i read again the spec and
made some other tests;

in fact, the problem i described cause no error because it is said that
"not all attributes are interpreted as attribute value
templates.../...attributes of top-level elements (.../...) are not
interpreted as attribute value templates"

so, the example above works perfectly because <data:foo bar="{$data}"/>
is one of the top level elements

the processor is strictly conformant to the spec, because the following
case :
<xsl:styleshe et ...>
<data:foos>
<data:foo bar="{$data}"/>
</data:foos>
...
</xsl:stylesheet>
causes an error, and that's my really problem

however, i really think it shouldn't be interpreted as avt, because the
purpose of the avt is to perform computation on literal result element;
in my case, it is not literal result element because this xml structure
is out of the scope of the processor : "an XSLT processor (.../...) must
ignore a top-level element without giving an error if it does not
recognize the namespace URI"; it is obvious that subelements should also
be ignored because the processor can't handle the result in any way, and
if i use the document('') function, i need to retrive the value {$data},
not the value {'{$data}'}
--
Cordialement,

///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------