XSLT 1.1 comments

There is good stuff here.  Formalized namespace handling, the elimination of 
RTFs, etc.

There is still no explanation of the "id" attribute on an xsl:stylesheet or 
xsl:transform element.

Note that the disallowing of attributes at the "root" of what used to be RTFs 
eliminates some cool hacks with aggregated attributes that I have seen and 
used myself in XSLT 1.0.  I don't think this is necessarily a bad thing, but 
it's worth noting.

OK.  Now into the darkness...

I'm not sure what the point is behind the statement

"If an external object is passed to an extension function with an 
expanded-name whose namespace URI is different from the namespace URI of the 
expanded-name of the extension function that returned that external object, 
the behavior is implementation-dependent."

As I see it, the "behavior" is implementation-dependent regardless of any 
issues of namespace URIs.  That's the very essence of an extension function, 
right?

"Issue (null-external-object): Should the spec have the concept that an 
external object may be null, and provide a way for testing this, for example, 
by conversion to boolean?"

Of course it shouldn't.  Does XSLT really need full-blown language mappings in 
order to sort out what a "null" external object means in the various 
languages?  Is this just CORBA or DOM envy?

"Ed. Note: Define the idea that an external object "wraps" an object created 
by an external programming language."

This is just one of the manifestations of language-centric thinking that has 
unfortunately crept into the XSLT 1.1 spec.  This concept might seem 
attractive to people working in Java, C++ or Python.  But it is by no means 
universally applicable.  I also don't see its use.

In the xsl:script section, please drop the "ecmascript" | "javascript" | 
"java" nonsense from the "language" attribute specification.  This just 
inflames those of us who worry about the W3C's language bias.  Popularity is 
not even a good excuse, since VB is probably a more popular scripting language 
for XSLT extensions than Java.  It's also totally unnecessary.

In general, I think the re-introduction of xml:script is execrable.  XSLT 1.0 
had perhaps the most elegant extension model possible, and xsl:script ruins 
this by destroying the opacity of extensions to XSLT processors.  Language 
bindings may make sense in the realm of CORBA or DOM, where the actual 
expression of the program is done in the bound language, but XSLT is XSLT, and 
introducing the need for language bindings only reduces general 
interoperability while giving a small boost to interoperability between small 
axes of implementations.  In fact, I get the impression that it was the 
Saxon-OracleXSL-Xalan-J axis that brought this about.

The political warning is that Microsoft as an axis of its own, has much 
broader XSLT presence than the Java band, and a move that I'm guessing is 
intended to make the Java implementations more attractive is *very* likely to 
backfire as we all have to start dealing with transforms with embedded 
VBScript.

At a stroke, the specification makes it more attrctive for Sun (just to pick 
on someone other than Microsoft) to make its SVG slide toolkit only useful to 
Java programmers.  As pure XSLT 1.0, it was useful to all.

This is a very bad thing.

Moving on...

Suggestion: Add some discussion of the behavior of stylesheet processors with 
XIncludes in the stylesheet or source document infosets.

Minor suggestion: does it make sense (in XPath, of course), to make the 
namespace-uri() of a namespace "http://www.w3.org/2000/xmlns/" in accordance 
with DOM level 2?


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

Received on Sunday, 11 February 2001 08:45:22 UTC