[xslt] Validation of the content of xsl:template
- From: "Buchcik, Kasimier" <k buchcik 4commerce de>
- To: <xslt gnome org>
- Subject: [xslt] Validation of the content of xsl:template
- Date: Mon, 8 May 2006 20:34:46 +0200
Hi,
This issue is related to
http://bugzilla.gnome.org/show_bug.cgi?id=33922.
Spec: There must be no content before an xsl:param inside an
xsl:template.
I want to ask the list to what extent we should fix the validation
of the content of xsl:template. I'm asking this in order to see
what impact this would have on existing stylesheets.
Does someone rely on output of text or literal result elements or
whatever before an xsl:param inside a xsl:template?
If someone does rely on this incorrect behaviour, shall we just
fix it or somehow preserve the current state?
Example - the following incorrectly does not raise an error currently
(note the content before xsl:param here):
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xsl:if test="true()">
<foo/>
</xsl:if>
<xsl:param name="foo"/>
<bar/>
</xsl:template>
</xsl:stylesheet>
A strict validation of the content will have also impact on scenarios
using xml:space="preserve".
Example - this stylesheet is not valid, since it has a text-node
before xsl:param; although it's a whitespace-only text-node, the
xml:space does preserve it. Currently this text-node is incorrectly
treated as "template" content, thus added to the output tree.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/" xml:space="preserve">
<xsl:param name="foo"/>
</xsl:template>
</xsl:stylesheet>
As per XSLT 1.0, the above example is incorrect.
XSLT 2.0 stripps whitespace-only text before xsl:param
regardless of what xml:space indicates.
So we have the following possibilities:
1) Keep the broken behaviour.
This would obviously change nothing.
2) Apply validation as defined by XSLT 1.0
This would raise errors in existing broken stylesheets.
3) Go the XSLT 2.0 way and strip the whitespace.
This would raise no error, but produce a different result.
Thoughts?
Regards,
Kasimier
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]