Re: [xsl] a weird bug today, tree seems to change mid transform

Subject: Re: [xsl] a weird bug today, tree seems to change mid transform
From: Abel Braaksma <abel.online@xxxxxxxxx>
Date: Sat, 08 Sep 2007 12:21:10 +0200
Hi Bryan,

I was reading through your story and as far as I can tell, there is no bug that causes danish text to be translated automagically into english text ;)

Though I was wondering whether you'd already tried the following things to narrow your problem down a bit:

1. Use a copy template to find out what the source really looks like when it is processed by the XSLT
2. If you can't do (1) because it is in the midst of a larger process, consider adding a node that is not recognized by the rest of the process and copy the input document into it for analysis (it should give 'more').
3. You seem to get your different outputs based on changes in the matching template match attribute (your follow up post). Does the stylesheet use xsl:import or xsl:include? Are there other places that may receive a higher priority? In essence: I think your @x with different outputs does not come from different calls to translate(), but from different stuff in your input XML (which may very well be modified on the fly). To find this out, change your xsl:value-of to contain the generate-id(@id) as well, plus an xsl:copy-of the attribute and place the translated attribute in a new one.


In addition, you may want to try two more things: do a complete copy of the source again, in three ways:

1. use copy-of (that really should not impose extra processing, the operation is atomic)
2. use copy for shallow copy
3. use copy and translate(., 'ABC...', 'abc....') on *every* attribute, name etc:


<xsl:template match="*">
   <xsl:element name="{translate(name(), $up, $down)}>
      <xsl:apply-templates select="node() | @*" />
   </xsl:element>
</xsl:template>

<xsl:template match="@*">
   <xsl:attribute name="{translate(name(), $up, $down)}>
      <xsl:value-of select="." />
   </xsl:attribute>
</xsl:template>

<xsl:template match="text()">
   <xsl:value-of select="{translate(name(), $up, $down)} />
</xsl:template>


If the only node that gets translated into English is now the Andet node, I'd be surprised. If everything gets translated into English, I'd like to buy your product: very handy haha. Hopefully it will show you some pointers....


It is not a solution, I know. It sounds as if the default extension prefix for functions is set to an empty string (which is not possible) and that translate() is also an extension function. You can test this by adding your own version of translate() with the proper extension in an msxml script block, i.e. with C# of VBScript code. It shouldn't be too hard and at least (even if you do not have the problem solved) you can continue working using your own my:translate(. $up, $down) (and if you are busy with it, just use the regex engine of VBScript/JScript, it will make your templates easier).

Good luck with it,

Cheers,
-- Abel Braaksma





bryan rasmussen wrote:
Hi,

I had to edit some parts of a big old legacy application today. I had
access to its XSLs. Actually the XSLs were in wd-xsl but I had
permission to change it to XSL-T (1.0). So I did. One thing that might
be pertinent to this story (I am not certain) is that the xsl-t
processor  used was msxml 2 (because of the wd-xsl) I did not have
permission to change this.

I had three elements one of which had to not be processed: the tree
was like the following

<x x="Kend"></x>
<x x="Personer"></x>
<x x="Andet"></x>

it was the x where the attribute x= Andet that was not to be
processed. I did a bunch of stuff, I did:

<xsl:template match="x[@x='Andet']"/>

I did choose whens I did all sorts of stuff. Andet kept being
processed. I copied out the XML. It came out as shown (well actually
the above is a simplification but only in not having longer names and
attributes)

I was really freaked out. I check with contains(@x,'Andet')
no it does not contain Andet, I check with contains(@x,'A') yes it
does, actually all of the do, even the ones where the attribute x does
not have an A in it.

so at this point I do all sorts of checks, among which I do
translate(@x,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz')
and put it in a variable x.

then I check does $x ='andet' no it does not. I output the value of
$x. The value of $x = more.
Now this is where things get weird.

you see I know this application has some sort of XML based translation
between languages. You know the sort of thing, an XML document with
the words that are meaningful in different languages and dependent on
which language the application is configured to all buttons and so
forth come out with the pertinent text. Andet which is Danish in
English is More. Furthermore all the other values of x which I was not
able to get either have their english values when the xpath translate
function is run over it.

So I test. If I write
<xsl:value-of select="@x"/> it equals Andet.
If I translate it using xpath translate it equals more.


The XSL-T does not have any msxml extensions in it. There are no included or imported stylesheets to mess with anything. It is basically just that the value of the attribute x seems to be slightly more unstable than one is used to.

Now if it was in wd-xsl I could understand because there was a bug
associated with that so many years ago whereby one could alter the
tree during the transformation. But I am not aware of any such bug for
XSL-T even in such an old version of MSXML. It seems most likely that
the XML is being altered somewhere at the higher server level, but I
am not aware of any way that one can alter the XML mid-transformation
in any of the APIs available under MSXML. I don't really have access
to the server side but it may be that I will get it when the bug
report goes back to the central office. But what I am wondering, has
anyone ever seen a similar error, is anyone aware of a bug in earlier
versions of MSXML that can cause this?

Believe me, this does not require the XML or the code. you cannot
replicate the error with the code and the extracted XML. If I copy the
XML into the output and then save it and run my transform everything
works as it should. (I ended up by having to remove the x with x=
Andet by counting the preceding siblings. an atrocious hack)

Cheers,
Bryan Rasmussen

Current Thread