Re: Which engine? (RE: JavaScript and XSL)

[Paul Tchistopolskii <paul at qub dot com>]

----- Original Message ----- 
From: Steve Muench <smuench@us.oracle.com>

> | After I realized that SAXON ( which is very good 
> | engine) makes hidden RTF->node-set typecast 
> | ( the thing MS were blamed for ),  I feel not 
> | comfortable when somebody says 
> | 'conformant XSLT engine'  in public place.
> 
> This appears to have changed between Saxon 5.4 and Saxon 5.5
> I went back and tested the following stylesheet with Saxon 5.4...
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <test xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>   <xsl:variable name="x"><one><two>three</two></one></xsl:variable>
>   <xsl:value-of select="$x/one/two"/>
> </test>
> 
> and Saxon 5.4 yields:
> 
>   At xsl:value-of on line 4 of file:/C:/TEMP/test.xsl:
>   Cannot convert value [** RESULT TREE FRAGMENT **] to a node-set
> 
> While Saxon 5.5 or 5.5.1 yields:
> 
>   <test>three</test>
> 
> The September 2000 MSXSL yields:
> 
>   Reference to variable or parameter 'x' must evaluate to a node list.
> 
> Both Oracle XSLT and Xalan flag it as an error as well.

So this is a bug in latest SAXON ( I've tried 5.5 )  

Ah ... I'll be happy ( and I think everybody will be happy )  
if this will be not a 'bug' , but standard behavior.

I'm sure that because every engine already provides 
RTF -> node-set typecast as extension function, 
it will be one day of work to replace "report error" 
with "silent typecast".

Then users will not waste their time trying to 
understand "what is RTF" , 'what is "node list"'
( It seems that MS diagnostics is confusing.
I don't know about anything called "node list" )

But this requires changing the W3C paper - and 
... let us see how long it will take to change 
something in W3C paper. 

After that change in W3C paper we'll have to 
change our stylesheets ( because current syntax of 
extension functions is engine-specific ). 

Is there any chance that vendors will provide a
special command-line parameter "don't ask 
for the explicit conversion" ? This will allow 
writing reasonable (and portable) stylesheets 
conformant to XSLT v 1.1. 

When the flaw in design is obvious ( and this 
typecast is discussed on the list for years ) 
I think usually people change the software 
to make the flaw disappear as soon as it's possible - 
( why forcing users to pollute thier stylesheets? ) 
for some reasons this is not the case with XSLT.

I still think MS made a mistake, removing the 
typecast. On another hand it could be that 
if MS will not remove it, we'll never get the 
typecast removed. 

Soo funny.

Look - the standards are about agreement on
some technology. 

For years everybody knows that 
RTF / node-set distinction is bad thing with 
no rationale behind it ( if there is any rationale - 
where is it? For years - not a sign of 
explanation ). This distinction is a standard 
and remains a standard. 

I don't understand how this is happening.

The only rationale I can think about is : 
"it is good for you code if you specify the 
typecast in the code". But the xt:node-set 
typecast  itself in *not* in the WD - so this is 
not the case!

I'm sure almost every developer at some point of time
decides: "OK, I'll place this lookup tree into the variable" - 
and then he fails to do that.

And for years - nobody cares. Why? This affects many stylesheets.
This is extremely simple to fix - ( as I've said - it should be just one 
day if not 30 minutes ).

Why this is happening? Why 30 minutes fix which looks unavoidable 
should wait for years to happen? 

Rgds.Paul.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list