Re: [xsl] XSLT 1.1 comments

Subject: Re: [xsl] XSLT 1.1 comments
From: Daniel Veillard <Daniel.Veillard@xxxxxxx>
Date: Tue, 13 Feb 2001 10:31:31 +0100
[Cc'ing xsl-editors for W3C archiving]

On Mon, Feb 12, 2001 at 06:51:12PM -0800, Steve Muench wrote:
> The XSLT 1.1 spec is a first working draft, so I don't understand
> why you're throwing in the towel already! :-)

  Well this is in the XSLT-1.1 requirement document ... Theorically
all this thread is not only feedback on the XSLT-1.1 WD but also on
the XSLT-1.1 Requirement WD:

> The very nature of Working Drafts is to get user community
> feedback *before* it's too late.
> So far, on this thread, we've heard feedback from a few
> XSLT processor implementors:
>    FourThought, makers of 4XSLT (a Python XSLT 1.0 implementation)
>    Unicorn Enterprises, maker of Unicorn XSLT (a C++ XSLT implementation)
>    Daniel Veillard, maker of libxml-based XSLT processor (in C, I believe)

  yes it's in C. Obviously C(++) based implementors are the ones for which
xsl:script Javascript and Java support looks really broken, implementing
those mean increasing the system requirement needed for implementation
a lot. Basically it promises us to be relegated to the rank of implementors
of a subset only of the spec, i.e. being considered toys in the eyes of
anybody looking at implementations with a spec conformance point of view.
  The comparison with xsl:output is enligthening, who would purchase or
use an XSLT processor not able to generate a serialization. If you don't
you cannot be considered a general purpose XSLT processor. I'm afraid it
will be the same with xsl:script . The idea of being restricted to a niche
because you selected a different implementation language ain't really fun.

  From a free software point of view Java is not that well perceived
for a variety of reasons, if your server runs some BSD or a mips based
Linux os, good luck finding a Java implementation free and reliable 
enough to make your server side scripting relying on it. Javascript
implementations are easier to find (and ECMA is a standard, it helps).
Having worked on the Kaffe early Java/C binding, I must say that the idea
of having to fiddle with this mess again doesn't sound like fun.

> Other than the few good points about making the spec clearer,
> the executive summary of the feedback seems to be "why are Java
> and ECMAScript special?"

  Well my feedback would rather withing the tone "please get rid of
xsl:script", or "please move xsl:script to a non-normative section".
The problem is not with language A or B, it's about the fact that the
spec is no more precisely bound. Extension functions were okay because
they limit the amount deviation (and relatively easy to detect and handle),
it's not the case for scripts.

> We encourage any additional feedback.

 Ok other points of XSLT-1.1 feedback, I think I implement
XML Base support, libxml base lookup function checks xml:base and
libxslt reuses it. I will add a few test cases for this.

 Another feedback is that E2 example, the SVG output should have
a doctype declaration.

 I think the conformance section needs to be revamped (or you will get
troubles trying to go throuh the Director decision anyway), I think
it must explicitely state:
  - if a 1.1 processor must recognize 1.0 and try to implement 1.0
  - it would be good if that section could state black on white 
    how an 1.1 processor should work when processing an 1.0 stylesheet
    w.r.t. XML base and result tree fragment data-type handling.
  - it shoud explicitely list all optional features, currently it
    just lists output.

 Last but not least, the colored diffs (and appendix G) is a precious
resource, please try to keep them even when publishing the REC,



Daniel Veillard      | Red Hat Network
veillard@xxxxxxxxxx  | libxml Gnome XML toolkit | Rpmfind RPM search engine

 XSL-List info and archive:

Current Thread