Re: [xsl] XSLT 1.1 comments

[Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>]

> > introducing the need for language bindings only reduces general
> > interoperability while giving a small boost to
> > interoperability between small axes of implementations.
> >
> I don't understand. How can defining a Java language binding which
> implementors are at liberty to implement or not, reduce interoperability
> when compared with allowing each implementor to invent a different Java
> language binding, which is the current situation at XSLT 1.0?

I'll respond to your question, but first let me ask a question of my own that 
is the heart of the matter to me.

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.  What's so special about XSLT that 
crutches have to be hard-wired in for the Java folks?

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.  At some point they might 
come across a situation that needs extensions, but puuting this in place was a 
separate operation with their stylesheet processor which set up an 
*environment* for the opaque extensions within XSLT itself.  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.

And there are problems galore once we move back to computer engineering.

The xsl:script section contains all sorts of horrid prescriptions.  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?

BTW, why are the language names other than the Sanctified Three specified as 
Qnames?  What is this supposed to look like?

{http://microsoft.com}VisualBasic   ???

Why is this necessary?

"When a function implementation is provided locally in the content of the 
xsl:script element, the src attribute must not be specified."

This language means that a stronger statement has to be made than

"XSLT processors are not required to support any particular language binding. 
xsl:script elements with language values not supported by the processor are 
ignored."

It should also point out that the processor need not check any conformance 
constraints made with regard to xsl:script elements in an unsupported language 
binding.  Basically, that "ignore" is not clear as to whether it refers to 
structure or processing.

It is also unclear as to how xsl:script interacts with fallback.  If there is 
a script element and my processor does not not support it and there is a 
fallback for that element, can I ignore the fallback and use a separately 
registered extension module for that namespace URI?

All of this complication would be reduced if language bindings were left to 
additional layers on XSLT as appropriate.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +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