Re: [xsl] XSLT 1.1 comments

["Steve Muench" <Steve.Muench@xxxxxxxxxx>]

| Actually, I missed the fact that DOM has an appendix with a Java binding.  
| This is probably because at least they kept the Java-centricity strictly to 
| that appendix.  XSLT 1.1 does not do so.
| 
| I still think that the DOM decision is a mistake as well.  The Java binding 
| should be a separate effort and Java download.

I respect your right to have your own opinion on this matter.

| > Are you essentially saying that you want writing extension functions
| > in Java or ECMAScript to be equally complicated to providing them
| > in any language?
| 
| No.  Equally as easy.  Just as they are in XSLT 1.0.  You still haven'tpointd 
| out why this is not so.

If you're definition of easy is that as a developer I need to remember
5 different ways to use extension functions because I happen to use
5 different XSLT 1.0 processor implementations, then we'll have to
agree to disagree on our interpretation of the word easy.

(Lightbulb going off)

Perhaps where we differ is that you're trying to see how XSLT 1.1
makes the life of the XSLT Processor *implementor* easier. That's not
the point. The point is to make the life of the XSLT *developer* easier.

| If that were all, I hardly think it would warrant a change in the spec.  I'm 
| sorry, but it looks like play for establishment to me.  And I bet it does to a 
| lot of othe non-Java folks (and probably some Java folks).

I'm afraid I don't understand what a play for establishment means.
Establishment of what? by whom?

| > So whether it is language="java" or language="xsl:java", does this
| > make a big difference?
| 

| If it's such a small matter to you, why don't you take it out?

My point is that it's just a small syntactic matter. Removing
the extension language functionality puts developers back in
the situation they are in now, having to learn 5 different
mechanisms for 5 different processor to accomplish what
to them is effectively the same task: implement an extension function.

| > | The first problem I see with xsl:script is the human engineering aspect.  XSLT 
| > | 1.0 had extensions but had the admirable quality that extensions were opaque 
| > | to XSLT itself.  This encourages people using XSLT to have the XSLT mind-set 
| > | and learn how to solve problems within the language.
| > 
| > With all due respect, I don't buy this argument. When people haven't been 
| > able to figure out the "XSLT Way" to do something, they've turned to
| > built-in extensions like saxon:node-set, ora:node-set, xt:node-set, or
| > extension elements like <saxon:document>, <ora:document>, or <xt:document>.
| 
| Yes.  And it is clear at that point that they are deviating from XSLT.  With 
| xsl:script, this is quite blurred.

It seems crystal clear to me. The <xsl:script> element clearly
binds an extension function namespace to a set of extension functions
in a particular language. It also provides the details for
a processor to recognize whether or not is supports the
language. Extension functions do not REQUIRE an <xsl:script> to be
used, so supporting any number or built-in extensions, or any
consciously-proprietary mechanism for doing the binding that
<xsl:script> accomplishes is your choice.

| > In the case of SAXON users, they enjoy a huge variety of built-in extension
| > functions that Michael Kay has diligently been adding in response to user
| > feedback. These vendors could have gotten together, agreed on a common
| > namespace, and agreed to implement some <common:document> and common:node-set()
| > function. But then user-written extensions cannot enjoy this same portability
| > since the user writing the extension cannot control the binding between the
| > XSLT processor and the extension function implementation language.
| 
| I don't understand this.  Why can't they?  Why can't processor implementors 
| band together to sort it out?

Many of them did, in the context of the W3C XSL WG's XSLT 1.1 effort.
The implementors of MSXSL3, OracleXSL, Xalan, xsltc, XT, Saxon, and NovellXSL
all contributed to the effort. The intent of all of these cooperating
people was to come up with a language neutral binding mechanism, and
the concrete details of a few specific language bindings. The Working Draft
process lets us get feedback from other users and XSLT processor implementors
that were not on this initial group of folks.

| In fact, why can't XSLT implementors in Python, C++, VB, Perl, Java and other  
| languages work together on this?

They could. Even big companies have limited resources. We chose
to focus ours on the W3C process, where we were already participating.

| You want a portable saxon:evaluate?  Fine.  I do too.
| 
| 4XSLT has ft:evaluate.  Let's all talk about it and put together a set of 
| extensions, one of which is *:evaluate.
| 
| Then we get an NSRef.  Obvious choice is to form an OASIS TC and get
| 
| http://xml.org/xslt-extensions
| 
| Then we can all replace our *:evaluate with one in that NS, and Stylesheet 
| processors can then announce their support for OASIS TC on XSLT Extensions.
| 
| And without touching XSLT 1.0 we will have achieved everything XSLT 1.1 
| claims, but in a language-neutral way, and a way that respects the layering 
| between XSLT and extensions.

You continue to focus on *Built-in* extensions. The <xsl:script>
targets user-written extensions. There is no change in XSLT 1.1
with regard to *Built-in* extensions.
 
SAX has been successful with a similar kind of out-of-band approach.
As has the TRAX effort that fed into JAXP.

Even big companies have limited resources. For this effort, we choose to
focus ours on the W3C process, where we had a large group of implementors
that were interested in working together on a portable extension mechanism.

| I get the impression that xsl:script has been hacked in for the benefit of 
| Java and that worries with regard to other languages are secondary.

The group worked for many months on coming up with the current draft sections
on extension functions. What are the specifics that make it not work for other 
languages?

Besides repeating the argument that you think the facility is
"odious", "execrable", and "horrid" (no need to rain additional
adjectives on it), working with us to point out what about our
design does not work for the languages you care about would be
a constructive contribution you can make.

I know you response will be, "Why should I make a constructive
contribution to an effort that I think should be eliminated immediately?!?!?"
But, ever the optimist, I'm crossing my fingers...

| > | BTW, why are the language names other than the Sanctified Three specified as 
| > | Qnames?
| > 
| > The 'language' attribute on <xsl:script> is designed to work *exactly* like
| > the 'data-type' attribute on <xsl:sort> and
| > the 'method' attribute on <xsl:output>
| > 
| > Just as you can say:
| > 
| >    <!-- I'm not a python programmer, take example with grain of salt -->
| >    <xsl:sort data-type="fourthought:pythonNumber"/> 
| > 
| > or
| > 
| >   <xsl:output method="fourthought:mySuperSerializer"/>
| > 
| > you follow this same approach and do something like:
| > 
| >   <xsl:script language="fourthought:python"/>
| 
| Do I really have to explain why these matters are not equivalent?

Sure. It would help lend some needed technical weight to your
repeated "I don't like this. I don't like this. I don't like this"
mantra. The <xsl:script> is designed for extensibility by following
the same approach that other relevant XSL elements have used to
provide extensibility.

| > | Why is this necessary?
| > 
| > It's not. You can continue to provide proprietary ways
| > to specify extension functions if you choose. See the
| > editors not in section 14.4"
| 
| You can't show that it's necessary; you can show that it provides anything 
| over XSLT 1.0.  So why is it there?  Should every language interest strive to 
| insert their conveniences into the core spec as well?

If you choose to not listen or not understand, I cannot
control this. However...

I believe I've clearly explained why it's necessary:

   (*) In XSLT 1.0, user-written extension functions
       are not portable across XSLT processor implementations
       in any language. User's (not processor implementors
       but *users*) have expressed this as a problem.

       See: http://www.xmlhack.com/read.php?item=400
       for some pointers to xml-dev discussions on this.

I believe I've clearly explained what it provides over XSLT 1.0:

   (*) It allows user-defined extension functions to
       be portable across implementations in an initial
       set of languages, and its designed to work with
       any language in the future.

I agree with you that XSLT 1.1 does *nothing* to
improve portability of arbitrary *Built-in* extensions,
this was not its goal, but it does standardize the use of:

   -> <xsl:script> for defining user-written extension functions

   -> <xsl:document> for multiple output documents

   -> xsl:node-set() (or rather the lack of having to use it)
      to convert result-tree-fragments to node sets

All of which are done differently in different processors
in XSLT 1.0, complicating users lives who have to work
with multiple XSLT engines.

______________________________________________________________
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