Override of attributes from attribute set

--===============0487662617815249087==
Content-Type: multipart/alternative; boundary="0000000000009aae75059982b9cf"

--0000000000009aae75059982b9cf
Content-Type: text/plain; charset="UTF-8"

We've been struggling with an elusive bug which had us baffled for a while.
The XSL/T spec says that if you attach an attribute directly to a literal
element, which also pulls in that attribute with an xsl:use-attribute-sets
attribute, then the attribute specified on the literal result element will
override the value set in the attribute sets. This has worked fine for
years, and then all of a sudden table borders started disappearing with no
explanation, and the same code would produce different output on the lower
tiers than what we got on the production server. I was able to determine
that libxslt version 1.1.29 was handling the attributes correctly, but
1.1.30 was not, nor was 1.1.33. I was preparing a repro case so I could
file a bug and then I discovered that the latest version of the Python lxml
package is built and distributed with different versions of libxslt,
depending which platform OS is targeted, and when I tested on my MacBook,
the repro case didn't reproduce the failure. The version of libxslt on that
machine was 1.1.34, which appears to have fixed the regression. So the only
remaining puzzle is: why is there nothing in the bug tracker (would have
saved a bunch of time and work)? Did this really get discovered and fixed
without a ticket? Or did the bug get introduced _and_ fixed accidentally,
without anyone noticing either change? Or is there a bug report in the
tracking DB that I'm just not seeing? If the bug really did come and go
without anyone being aware of it, and you would like to record it (if
nothing else, adding to the regression test suite), I'd be happy to provide
my repo case. If there's an appropriately titled bug report, and my old
eyes and/or brain are just too dim to have found it, please accept my
embarrassed apologies. :-)

Thanks!

-- 
Bob Kline
https://www.rksystems.com
mailto:[email protected]

--0000000000009aae75059982b9cf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif">We&#39;ve been struggling with an elusive bug which had=
 us baffled for a while. The XSL/T spec says that if you attach an attribut=
e directly to a literal element, which also pulls in that attribute with an=
 xsl:use-attribute-sets attribute, then the attribute specified on the lite=
ral result element will override the value set in the attribute sets. This =
has worked fine for years, and then all of a sudden table borders started d=
isappearing with no explanation, and the same code would produce different =
output on the lower tiers than what we got on the production server. I was =
able to determine that libxslt version 1.1.29 was handling the attributes c=
orrectly, but 1.1.30 was not, nor was 1.1.33. I was preparing a repro case =
so I could file a bug and then I discovered that the latest version of the =
Python lxml package is built and distributed with different versions of lib=
xslt, depending which platform OS is targeted, and when I tested on my MacB=
ook, the repro case didn&#39;t reproduce the failure. The version of libxsl=
t on that machine was 1.1.34, which appears to have fixed the regression. S=
o the only remaining puzzle is: why is there nothing in the bug tracker (wo=
uld have saved a bunch of time and work)? Did this really get discovered an=
d fixed without a ticket? Or did the bug get introduced _and_ fixed acciden=
tally, without anyone noticing either change? Or is there a bug report in t=
he tracking DB that I&#39;m just not seeing? If the bug really did come and=
 go without anyone being aware of it, and you would like to record it (if n=
othing else, adding to the regression test suite), I&#39;d be happy to prov=
ide my repo case. If there&#39;s an appropriately titled bug report, and my=
 old eyes and/or brain are just too dim to have found it, please accept my =
embarrassed apologies. :-)</div><div class=3D"gmail_default" style=3D"font-=
family:arial,helvetica,sans-serif"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif">Thanks!</div><div><br></div=
>-- <br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_=
signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>Bob Kline<div><a hre=
f=3D"https://www.rksystems.com" target=3D"_blank">https://www.rksystems.com=
</a></div><div>mailto:<a href=3D"mailto:[email protected]" target=3D"_bl=
ank">[email protected]</a></div></div></div></div></div></div></div>

--0000000000009aae75059982b9cf--

--===============0487662617815249087==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
xslt mailing list, project page http://xmlsoft.org/XSLT/
[email protected]
https://mail.gnome.org/mailman/listinfo/xslt

--===============0487662617815249087==--