This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XSLT 1.1 comments


| and alternatively:
| 
| -> if two conforming XSLT 1.1 processor implementations both
|    have elected to implement the C++ language for extension
|    functions, then developers can expect that ...
|        Really, what can we expect in this case?

At a minimum, they can expect exactly what they can
expect in XSLT 1.0, that is, nothing.

Doing better than that, XSLT 1.1 provides an extensible
<xsl:script> mechanism for vendors to cooperate to agree
on a common C++ language binding, with a common QName
that describes the binding and which can be used in
the <xsl:script language="QName"> construct.

If the vendors do *not* want to cooperate to come up with
a C++ specific binding that they share, then they are
in the same situation as with XSLT 1.0.

Net net, XSLT 1.1 neither promotes nor hinders this from happening,
but it provides a new mechanism to make it possible, should it
be the will of the web community.

| > ... Microsoft's
| > MSXSL3 and Unicorn which both might offer only ECMAScript language.
| > 
| 
| They both are going to offer C# extensions as well. 

Great. You will have the choice of implementing a standard
C# language binding, or two each go your own way depending
on which option is best for your mutual business needs.
This is the same as for Java and ECMAScript. As I mentioned in
my previous post, you *always* have the option of going your
own way, that is, by creating your own language="Qname" that
describes your binding.

| I am wondering - how will they manage to get interoperable
| implementations? 

If you agree on a binding, and agree on a Qname to describe
that language binding, then they will, independent of the W3C.

   <xsl:script language="SomeCommonOrg:csharp">

If you do not choose to agree on a binding, you'll both provide
your own distinct QName's for the language:

   <xsl:script language="ms:csharp">

   <xsl:script language="unicorn:c-sharp">

Perhaps mutual customer feedback on the importance or lack thereof
of stylesheet portability might influence the two (or more) 
parties one way or the other? Not sure.

| Maybe, XSLT 1.1 will help them?

Again, XSLT 1.1 offers no magic to compel companies to
agree on bindings. It offers three standard DOM2-based
bindings (IDL/DOM2, ECMAScript/DOM2, and Java/DOM2) and
leaves the door open for the W3C or external organizations
to create more as the market demands.

______________________________________________________________
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]