Subject: Re: [xsl] a weird bug today, tree seems to change mid transform From: "bryan rasmussen" <rasmussen.bryan@xxxxxxxxx> Date: Sat, 8 Sep 2007 09:38:44 +0200 |
I didn't have to, I was using XSL-T. On the server side I am assuming that there is other stuff going on that makes the language translation, but how it affects the DOM I get is a mystery. These varying results on the same attribute were achieved in the same transform. The only thing I could conceive of causing it was a bug in this early version of MSXML. Unless the original developers found some way to redefine translate, but why would they do it and how does one do it so it affects the XPath functions in a transform?!? It was frankly mind blowing, especially as there are over 500 errors that have to be fixed in this system and I'm sitting and thinking how can one with any reliability fix errors in a situation like that (most of the errors are not xsl errors but errors in a proprietary 4GL). I mean if I ran <xsl:variable name="caption" select="translate(@x,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz'')"/> <xsl:variable name="capt2" select="translate(@x,'A','p')"/> x=<xsl:value-of select="@x"/> caption=<xsl:value-of select="$caption"/> capt2=<xsl:value-of select="$capt2"/> <xsl:copy-of select="self::*"/> I get x=Andet caption=more capt2=More <-- can things get any weirder!!? <x x="Andet">..</x> So I was hoping someone knew of a particular bug or hack for the processor that could result in this kind of bad result. The bug I can think of affects wd-xsl http://support.microsoft.com/kb/262236 but I had changed the wd-xsl they were running in that particular view to be XSL-T. Cheers, Bryan Rasmussen On 9/8/07, Joe Fawcett <joefawcett@xxxxxxxxxxx> wrote: > Bryan > > Did you force it to use XPath? > > doc.setProperty("SelectionLanguage", "XPath") > > -- > > Joe > ----- Original Message ----- > From: "bryan rasmussen" <rasmussen.bryan@xxxxxxxxx> > To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> > Sent: Friday, September 07, 2007 8:14 PM > Subject: [xsl] a weird bug today, tree seems to change mid transform > > > > 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] a weird bug today, tree s, Joe Fawcett | Thread | Re: [xsl] a weird bug today, tree s, Abel Braaksma |
Re: [xsl] a weird bug today, tree s, Joe Fawcett | Date | Re: [xsl] In Search of People Who K, Andrew Welch |
Month |