OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1



At 12:36 01/03/2001 -0700, Uche Ogbuji wrote:
>My main objection to the Jav and ECMA bindings are that they pollute the
>main XSLT spec and are given unseemly prominence therein, rather than
>being completely relegated to an appendix, as in the DOM binding.

In fact, if you look at the WD for DOM3-Core
(http://www.w3.org/TR/2001/WD-DOM-Level-3-Core-20010126/core.html) you'll
see that Java is not at all relegated to an appendix. Section 1.2 is
*entirely* about Java. I'm certain that the intentions behind that section
are good, and I am aware that it is only a WD but that section has nothing
to do there and I nevertheless find it's presence alarming. Either it ought
to describe bindings (and in this case, implementation because it's what it
does) for all languages succeptible of supporting a DOM interface, or it
should be language independent. A DOMImplementationFactory is probably a
good idea, describing that interface as part of the DOM is certainly enough.

As for xsl:script, I agree that it's an awful idea, and way too premature.
I think that the way forward re extensions in XSLT is to define an API to
load, register, and call extension code for functions, elements, and
objects. Adding xsl:script now will totally wreck XSLT, and ruin
portability. Using an API one could define a set of useful extensions
usable in any implementation language, whereas xsl:script is only usable if
the implementation provides the specific language that's used. Also, using
an API, implementations could make use of CORBA, (XML-)RPC and all sorts of
other schemes to have access to the required functionality.

Granted, defining such an extension API is harder, but imho it's the only
way to go. Mixing programming languages is nearly always a very bad idea,
I'd think that by now everyone would know that. On the other hand providing
clean abstraction layers so that they can cooperate is a good thing. Saying
that, I feel like I'm stating truistically obvious truisms. However,
looking at xsl:script I feel that there are people to whom it may be less
obvious. If xsl:script is there to stay, then for consistency's sake
xsl:blink should be thrown in too.

-- robin b.
Oops. My Brain just hit a bad sector.