This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: [xsl] XSLT 1.1 comments
- From: Uche Ogbuji <uche dot ogbuji at FourThought dot com>
- Date: Sat, 10 Feb 2001 18:18:04 -0700
- cc: xsl-editors at w3 dot org
- Reply-To: xsl-list at lists dot mulberrytech dot com
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
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list