This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT 1.1 comments
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Mon, 12 Feb 2001 17:19:50 -0700
- cc: xsl-editors at w3 dot org
- Reply-To: xsl-list at lists dot mulberrytech dot com
> > 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@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