Re: [xsl] XSLT 1.1 comments

[Uche Ogbuji <uche dot ogbuji at fourthought dot com>]

> | What was wrong with the extension mechanisms in XSLT 1.0 that couldn't be 
> | sorted out with a language binding *outside* the XSLT spec.  This is how DOM, 
> | CORBA, etc. handle language-specifics.
> 
> The XSL Working Group has done exactly what the DOM and SVG groups
> have done. All three provide language bindings as normative appendices
> to their specification. Not sure what you mean by DOM's handling it's
> language-specifics *outside* the spec. We specifically followed the DOM
> and SVG Working Group's lead on this area.

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.

> That said, there are C-based implementation of DOM's, but to my
> knowledge no *standard* api for C-based implementation of DOM's
> so perhaps the fact that the DOM spec includes a Java language binding
> an an ECMAScript language binding *has* made it easier for web
> developers working in Java and ECMAScript to apply the DOM to
> their daily work? That's clearly not *all* web developers but
> it is a non-zero sized population that has benefitted.
> 
> | What's so special about XSLT that crutches have to be hard-wired 
> | in for the Java folks?
> 
> 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.

> In effect, if I've understood you correctly, you
> are objecting to the existing of "shortcuts" for ecmascript and java?
> In the end, we're just saving a few characters. That is, as the 
> spec is written now...
> 
>    <xsl:script language="java">
> 
> is a shortcut for:
> 
>    <xsl:script language="someW3CPrefix:java">
> 
> which might as well be:
> 
>    <xsl:script language="xsl:java">

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

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

It does to me and, as you have heard, to others.  If it's such a small matter 
to you, why don't you take it out?

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

> 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?  Why change the XSLT spec?

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

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.

If politics preclude going through OASIS, no problem.  URIs are a cinch to 
acquire.

> | I think this 
> | healthy layering is a good part of the reason why there has been so much 
> | advancement of the state of XSLT practice in just one year: it was quite clear 
> | how to layer one's thinking between XSLT and extension.  With xsl:script, the 
> | layers are muddies, and I think it will lead people (who, after all often 
> | search for expedient over good sense) to jump in with extensions without mind 
> | to the inevitable interoperability problems.
> 
> | The xsl:script section contains all sorts of horrid prescriptions.
> 
> Rather than describing these as horrid prescriptions, I believe
> you are below correctly pointing out some places where the
> spec (remember, it's a FIRST WORKING DRAFT) needs to be clarified.

I call them "horrid" because they illustrate that the overall ramifications of 
xsl:script with respect to the many genera and species of programming language 
has not been properly thought through.

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.

Oftentimes horror is in the subtleties.

> | I'll just  run through the gamut
> | 
> | "The implementation of the extension functions identifies the local names of 
> | the functions that is is implementing."
> | 
> | Python's dynamicism means that these implementing functions can change.  Is it 
> | the statically defined or current dynamic function set that is used to map the 
> | local names?
> 
> As long as your processor implements function-available() correctly, does the
> spec have to specifically answer this question? I don't believe it needs to
> be concrete about this. If you have a suggested wording that would make
> this point more clear, please do forward it to xsl-editors@w3.org. 

In XSLT 1.0, function-available() rightly left this matter a matter to the 
processor.  XSLT 1.1 drags it into the transform source.

I'm hardly likely to suggest another wording when I think the entire section 
should be struck.

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

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


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python



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