0.9.9 vs client-side XSLT
Julian F. Reschke
I've been trying Mozilla with my XML/XSLT with each new release for some
time now, but have seen little progress with the transformations *I* am
using.
The current problems I'm seeing are:
1) The transformation generates HTML (using xsl:output method "html") with
embedded CSS stylesheet. This still doesn't get applied. From the change
log, it seems that the bug fix for this has been delayed again?
2) xsl:number doesn't seem to produce separator characters.
3) There doesn't seem to be a way to transform a RTF into a node set (all
other XSLT engines I'm aware of provide extension functions).
I'd really like to get my XSLT transformation of RFC2629-XML (RFC author
DTD) working better on Mozilla.Feedback would be appreciated.
Sample documents: <http://greenbytes.de/tech/webdav/rfc3253.xml> and
<http://greenbytes.de/tech/webdav/rfc2629.xslt> (yes, this is served with
wrong content-type).
Julian
Jonas Sicking
> embedded CSS stylesheet. This still doesn't get applied. From the change
> log, it seems that the bug fix for this has been delayed again?
There is a reviewed patch to fix this, chances are very good that this will
be fixed in the next release (1.0). For now you'll have to put the CSS in a
separate file and add a link to it (using <link rel="stylesheet">). This
assumes that the CSS isn't dynamically built of course.
> 2) xsl:number doesn't seem to produce separator characters.
The xsl:number support is very basic. We know it and we like to fix it,
however it's not an easy thing to implemement. For now I would recommend not
to use xsl:number and use position() instead. Of course that's not as smooth
and doesn't have as many features, but in most cases you can at least get
something working.
> 3) There doesn't seem to be a way to transform a RTF into a node set (all
> other XSLT engines I'm aware of provide extension functions).
Actually, for now you can just treat an RTF as a nodeset, doing $foo/bar etc
works fine. Once we fix this we'll probably implement a function that
converts RTFs to nodesets.
> I'd really like to get my XSLT transformation of RFC2629-XML (RFC author
> DTD) working better on Mozilla.Feedback would be appreciated.
If the above are the only things blocking you you should be able to at least
get something working in mozilla. Of course we are working hard on fixing
even these things, they are all known bugs.
> Sample documents: <http://greenbytes.de/tech/webdav/rfc3253.xml> and
> <http://greenbytes.de/tech/webdav/rfc2629.xslt> (yes, this is served with
> wrong content-type).
If it's the wrong content-types then it won't work in mozilla, we have no
intention to "fix" that.
Regards,
Jonas Sicking
Julian F. Reschke
news:a847ut$38...@ripley.netscape.com...
> > 1) The transformation generates HTML (using xsl:output method "html")
with
> > embedded CSS stylesheet. This still doesn't get applied. From the change
> > log, it seems that the bug fix for this has been delayed again?
>
> There is a reviewed patch to fix this, chances are very good that this
will
> be fixed in the next release (1.0). For now you'll have to put the CSS in
a
> separate file and add a link to it (using <link rel="stylesheet">). This
> assumes that the CSS isn't dynamically built of course.
Well, I'd rather wait for the fix...
> > 2) xsl:number doesn't seem to produce separator characters.
>
> The xsl:number support is very basic. We know it and we like to fix it,
> however it's not an easy thing to implemement. For now I would recommend
not
> to use xsl:number and use position() instead. Of course that's not as
smooth
> and doesn't have as many features, but in most cases you can at least get
> something working.
In the general case, this can become quite complex and probably won't
perform as well (CPU-wise)...
> > 3) There doesn't seem to be a way to transform a RTF into a node set
(all
> > other XSLT engines I'm aware of provide extension functions).
>
> Actually, for now you can just treat an RTF as a nodeset, doing $foo/bar
etc
> works fine. Once we fix this we'll probably implement a function that
> converts RTFs to nodesets.
Interesting, that's what my code is supposed to do, yet it doesn't seem to
work. Can you spot a problem in this statement?
<!-- emit it -->
<xsl:choose>
<xsl:when test="function-available('msxsl:node-set')">
<xsl:apply-templates select="msxsl:node-set($copyright)" />
</xsl:when>
<xsl:when test="function-available('saxon:node-set')">
<xsl:apply-templates select="saxon:node-set($copyright)" />
</xsl:when>
<xsl:when test="function-available('xalan:nodeset')">
<xsl:apply-templates select="xalan:nodeset($copyright)" />
</xsl:when>
<xsl:otherwise> <!--proceed with fingers crossed-->
<xsl:apply-templates select="$copyright" />
</xsl:otherwise>
</xsl:choose>
> > I'd really like to get my XSLT transformation of RFC2629-XML (RFC author
> > DTD) working better on Mozilla.Feedback would be appreciated.
>
> If the above are the only things blocking you you should be able to at
least
> get something working in mozilla. Of course we are working hard on fixing
> even these things, they are all known bugs.
>
> > Sample documents: <http://greenbytes.de/tech/webdav/rfc3253.xml> and
> > <http://greenbytes.de/tech/webdav/rfc2629.xslt> (yes, this is served
with
> > wrong content-type).
>
> If it's the wrong content-types then it won't work in mozilla, we have no
> intention to "fix" that.
No, I know that the server isn't configured properly. But maybe you want to
download both files separately and take a look yourself. At least the
node-set issue is strange.
Jonas Sicking
change
> > > log, it seems that the bug fix for this has been delayed again?
> >
> > There is a reviewed patch to fix this, chances are very good that this
> will
> > be fixed in the next release (1.0). For now you'll have to put the CSS
in
> a
> > separate file and add a link to it (using <link rel="stylesheet">). This
> > assumes that the CSS isn't dynamically built of course.
>
> Well, I'd rather wait for the fix...
Looking at your stylesheet i can only see advantages with having the css in
a separate file, but it's your choise of course.
> Interesting, that's what my code is supposed to do, yet it doesn't seem to
> work. Can you spot a problem in this statement?
>
> <!-- emit it -->
> <xsl:choose>
> <xsl:when test="function-available('msxsl:node-set')">
> <xsl:apply-templates select="msxsl:node-set($copyright)" />
> </xsl:when>
> <xsl:when test="function-available('saxon:node-set')">
> <xsl:apply-templates select="saxon:node-set($copyright)" />
> </xsl:when>
> <xsl:when test="function-available('xalan:nodeset')">
> <xsl:apply-templates select="xalan:nodeset($copyright)" />
> </xsl:when>
> <xsl:otherwise> <!--proceed with fingers crossed-->
> <xsl:apply-templates select="$copyright" />
> </xsl:otherwise>
> </xsl:choose>
This looks like it should work fine, though I don't like the general idea
since you rely on non-standard behaviour, even though you have many
fallbacks. Your stylesheet is a little too big for me to start debugging,
feel free to make a smaller one and post here or file as a bug. With
emphasis on small :-)
/ Jonas Sicking
Julian F. Reschke
maybe this helps. When for-each-iterating though a node-set that was
implicitly converted from a RTF, matching by qualified name doesn't seem to
work.
In my attempt to minimize the problem, I produced:
<?xml-stylesheet type="text/xsl" href="moztest.xslt" ?>
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0"
xmlns:saxon="http://icl.com/saxon"
xmlns:test="mailto:julian....@gmx.de"
xmlns:msxsl="urn:schemas-microsoft-com:xslt"
>
<xsl:output method="html" />
<xsl:template match="/">
<html>
<head>
<title>Mozilla test</title>
</head>
<body>
<xsl:variable name="test">
<xsl:call-template name="fill-var" />
</xsl:variable>
<p>
<xsl:choose>
<xsl:when test="function-available('msxsl:node-set')">
<xsl:variable name="ns" select="msxsl:node-set($test)"/>
<xsl:value-of select="count($ns/*)" />
/
<xsl:value-of select="count($ns/test:x)" />
</xsl:when>
<xsl:when test="function-available('saxon:node-set')">
<xsl:variable name="ns" select="saxon:node-set($test)"/>
<xsl:value-of select="count($ns/*)" />
/
<xsl:value-of select="count($ns/test:x)" />
</xsl:when>
<xsl:otherwise>
<xsl:variable name="ns" select="$test"/>
<xsl:value-of select="count($ns/*)" />
/
<xsl:value-of select="count($ns/test:x)" />
</xsl:otherwise>
</xsl:choose>
</p>
</body>
</html>
</xsl:template>
<xsl:template name="fill-var">
<test:x>1</test:x>
<test:x>2</test:x>
</xsl:template>
</xsl:transform>
The goal was to show that it displays "2 / 0" rather than "2 / 2". However,
*this* example actually hangs Mozilla (so I'm not sure whether this is a
different problem).
Regards, Julian
"Jonas Sicking" <sic...@bigfoot.com> schrieb im Newsbeitrag
news:a852dl$6p...@ripley.netscape.com...
Axel Hecht
let poppa talk:
Conceptually it's a bad idea to have RTF as nodeset, cause you insert
data into your source, kind of.
Well, must be the mozilla folks, but here goes a trick with yet another
file:
There is a way in the standard to work on multiple source docs, and
that's the document() function.
So you could do a
<xsl:variable name="copyright"
select="document('JuliansCR.xml')" />
That should work, though it's not necessarily speedy.
Very evil idea, if you have a internal dtd specifying a few IDs, you
could do document('#copyright'), even.
Though it might be a nice idea to factor your copyright data with other
stylesheets, giving favor to an external doc.
Axel
Julian F. Reschke
news:3CA97C35...@numerik.uni-kiel.de...
> Hey Julian,
>
> let poppa talk:
Axel, I'm well aware of the drawbacks of using RFTs as nodesets, but the
problems are going to disappear with XSLT 2.0 anyway. You have missed some
other parts where I need the conversion (where it's actually much harder to
do otherwise).
To be honest: why should I need to rewrite my whole XSLT (making it much
harder to read and to maintain) just to workaround something which seems to
be either an oversight (missing conversion function) or a bug (element
matching not working) in Mozilla?
Axel Hecht
As both of us are not part of the specifying body, we prolly shouldn't
argue about this.
As your stylesheet shows, there is no good way around this part of the
spec.
(Unless you use a 2.0 engine, hahaha (sorry)).
I have tripped over this myself, so you're not alone. And the good
reason is, as long as you adhere to the spec, you're in a good position
to argue against vendors, if you're not, you're alone. It's up to you.
Have a bunch of xsl:if to adapt to each engine you want to support, or
think if you can achieve what you want by features within the standard.
And we are accepting patches, of course. (Though in the current
situation they are more or less likely to land.)
This is really an evangelism issue. I think I had a good solution for
one of your problems, and I'm honestly not thinking that it's a perfect
thing to have RTF as nodesets.
I was really unhappy with telling you a way to cut your copyright from
your data, for example.
Bottomline: If you submit a patch, we will consider checking it in. (Be
aware of the infamous context branch, which will change the
infrastructure.) I don't see any of the three usual suspect putting up
with features that are neither part of the spec, nor a good performance
win.
Axel
Julian F. Reschke
I think the serious problem is that the XSLT engine actually does not comply
to XSLT 1.0 (allowing implicit casting of an RTF to a node set), however
*also* doesn't comply to the XSLT 2.0 draft (the node set does not work as
expected). I think either one of these should be fixed.
Julian
"Axel Hecht" <a...@numerik.uni-kiel.de> schrieb im Newsbeitrag
news:3CA9B6A8...@numerik.uni-kiel.de...