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

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

Paul,

As documented in the XSLT 1.1 Requirements draft at:

http://www.w3.org/TR/xslt11req

the XSL WG considers this a requirement for XSLT 1.1
See the "Requirements for Result Tree Fragment to Node-set
Conversion" section.

| 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. 

It is common practice in my experience to release
a product initially with some features restricted
until implementation experience provides enough
evidence that relaxing the restrictions will not
impose a performance or optimization penalty. We
certainly do this with new features in the Oracle
database, relaxing initial restrictions with 
subsequent releases as testing, performance, and
optimizations can be proven to handle the more
general-case usage of the feature.

I believe that this initial restriction, with
the aim to eventually relax it, was the spirit
in which Result Tree Fragment was introduced.
XSLT 1.0 was carefully designed to allow the
distinction between RTF and nodeset to disappear
in the future with no backward compatibility issues.
The XSLT extension function mechanism has served
its purpose to allow vendors to provide the
implementation experience that gives the Working Group
confidence that the XSLT 1.1 release is the right
time to relax the restriction.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/


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