Sorry about confusion in versioning.
>The XSLT spec, section 7.1.3 says:
>"The following are all errors:
>Adding an attribute to an element after children have been added to it;
>implementations may either signal the error or ignore the attribute.
>[...]"
>So version 0.36 behaved incorrectly since it accepted the attribute
>without any error.
One note however, specification talks about "children" - not the first
child. How can you be sure there is no other children nodes till you read
closing tag.
You could have something like
<option value="FL">Florida
<xsl:attribute name="selected">selected</xsl:attribute>
The Sunshine State
</option>
where "The Sunshine State" is another text mode or even another child
element:
<option value="FL">Florida
<xsl:attribute name="selected">selected</xsl:attribute>
The Sunshine State
<alt-name>Fla</at-name>
</option>
I see your point and I am not saying I am right. It's spec's flaw that it
allows too many interpretations.
It might be good idea to enforce handling all the attributes first but the
spec does not say that clearly - seems to me.
NS.
----- Original Message -----
From: "Kaiserovi" <[EMAIL PROTECTED]>
To: "Sablotron Mailing List" <[EMAIL PROTECTED]>
Sent: Thursday, July 20, 2000 6:40 AM
Subject: Re: [Sab] 3.6 - 4.0 differences (a bug or fix?)
> Nick,
>
> to avoid confusion, let me point out that the current release of
> Sablotron is 0.42, not 4.2.
>
> > 1. Why in v 4.0
> >
> > the XML like this started producing an error:
> >
> > <option value="FL">Florida
> > <xsl:attribute name="selected">selected</xsl:attribute>
> > </option>
>
> The XSLT spec, section 7.1.3 says:
> "The following are all errors:
> Adding an attribute to an element after children have been added to it;
> implementations may either signal the error or ignore the attribute.
> [...]"
> So version 0.36 behaved incorrectly since it accepted the attribute
> without any error.
>
> > 2. The other thing I noticed v3.6 was always un-escaping TEXT during
> > transformation. That was bad for cascading XSLT stylesheets since the
> > result output was not always a valid XML. So I guess even though 3.6
did
> > not support <xsl:output> the default method was "text". Now then, in
4.0
> > there is <xsl:output method="..."> but it can only be "xml" or "html".
>
> No, the text method should work as well, although there _was_ a bug
> related to it - could you test your files on 0.42 please?
>
> > I do
> > not know while "text" method was skipped but even then why "html" method
> > does not produce un-escaped values. What I mainly point is use of
> > "&nbsp;" in my XSL that I would like to see as " " after
> > transformation.
>
> The spec is perhaps not clear enough about this. My feeling is that
> using the html method, the '&' character is meant to be escaped in all
> places where it's not explicitly forbidden by section 16.2 (HTML
> Output). That's how Sablotron does it, anyway.
>
> > Why would I need to use <xsl:text
> > "disable-output-escape">... every time in XSL where I just want
" ",
>
> This is a question for the W3C...
>
> Tom
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
