Re: XSLT 1.1 comments

| If I want to assert that my XSLT processor is 100% XSLT 1.1 compliant then
| anyone who uses my processor should be confindent that it will correctly
| transform XML using any XSLT 1.1 compliant document.

This is already a tall order. If you modify this statement to say:

  anyone who uses my processor should be confindent that it will
  correctly transform XML using any XSLT 1.x compliant stylesheet
  which does not use optional features of XSLT 1.x

then I buy the premise. Already, the existence of the optional
extension functions in XSLT 1.0 means you cannot make a blind
guarantee like that.

| Now it just so happens that I wrote my processor in fortran. Either I 
| am not going to be able to claim to be compliant OR I am going to have
| to spend thousands of hours mapping java to fortran. 

You've misunderstood here. Your hypothetical FORTRAN-based XSLT 1.1 
processor does not need to implement extension functions at all. If it
*does* implement Java (why would it, but *if* it were to implement Java
extension functions), then it would have to implement its Java language
binding according to the spec.

| Now, if there is no xsl:script tag, then I don't have to worry about making
| those mappings because they are not part of the XSL namespace. This way, ALL
| XSLT 1.1 transforms will work (I'll make sure that other namespaces fallback
| gracefully). The fact of the matter is, NOT defining a language mapping is
| more interoperable than having one. 

Same comment as above. As soon as a user begins to use extension ELEMENTS
or extension FUNCTIONS in a stylesheet, all bets are off for portability.

| Not everyone needs to or even want to implement JAVA... Just ask Microsoft.
| In fact, other language bindings might be more useful than JAVA. 

Indeed. I don't expect Microsoft to implement the Java language
binding in an eventual XSLT 1.1 compliant processor. Since they 
already support ECMAScript extensions, they would likely support
those (but this is still talking hypothetically, as I know nothing
about their implementation plans).

| Now if having a common language mapping is so utterly important, then move
| it into another namespace (XSL-Scripting). 

<xsl:output> is an example of an element in the XSL namespace
which a processor is free to ignore if it does not do
serialization of the result tree. Section 16 of XSLT 1.0
spec says:

  If an XSLT processor outputs the result tree, it should do
  so as specified by the xsl:output element; however, it is
  not required to do so.

So there already are examples of <xsl:*> elements that
are not mandatory.

______________________________________________________________
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