Re: Status

Frans, et al.,

On Sat, Feb 04, 2006 at 01:55:31PM +0000, Frans Englich wrote:

[...]

> As mentioned in the article as well, XPath 2.0 provides this?
> 
> Wouldn't it be a great idea to not duplicate what XSL-T 2.0 already
> provides?  The XPath/XSL-T/XQuery specs are well written, strongly
> specified, and backed up by a good test suite. I see several reasons:
> 1) Spend energy on stuff not already done; 2) it's difficult and
> labour intensive to achieve a result of the same quality the
> XSL/XQuery WGs did; and 3) don't fragment the market and don't compete
> with XSL-T 2.0, that makes everyone happier.

I disagree; I believe that an EXSLT for XSLT 1 should try to provide any
functionality, for XSLT 1 users, that is considered generally useful by
those users.  To this end, I think that the XSLT 2 specification
provides a rich fountain from which to draw ideas for life-giving
draught in XSLT 1.  (Conversely, I also believe that EXSLT has been a
source of ideas for the XSLT 2 specification effort.)  I am specifically
and purposefully cherry-picking from the XSLT 2 specification family.

That said, I do agree that it is a duplicated specification effort (your
point 1), but I think in the short term this duplicated effort saves us
in implementation effort.  Consider the baseURI idea that I highlighted.
I can easily come up with a specification for this within EXSLT, and
then implementing it in a particular library (that already supports XSLT
1) is easy; in fact, in the space that I currently haunt it is a trivial
matter of changing a namespace declaration.

Fully implementing XSLT 2 (even a "basic XSLT processor" model) is a
significant project.

I think that the EXSLT project is most valuable as a path for users to
obtain XSLT 2 functionality without having to wait for an XSLT 2
processor.

Does that split the market?  Well, some segments of the market don't
have access to an XSLT 2 processor.  I believe that if EXSLT supports
the major "interesting" pieces of XSLT 2, then when more projects
support XSLT 2, users will more easily be able to migrate to XSLT 2,
thus unifying the market.  Until that time, users need to have access to
some of this functionality, which is where EXSLT fits in.

> I see the purpose of EXSL-T as to improve interoperability. Instead of
> that implementors implement their own similar but slightly different
> extensions, it's done in a standardized way. I think that thinking
> would be enhanced by filling the holes XSL-T 2.0 has, instead of
> adding a similar but slightly different layer.

Originally, I believe EXSLT was targeted at only specifying extensions
for XSLT 1.  As your message and Dimitre's earlier message in this
thread show, there is increased interest in EXSLT for XSLT 2.  As you've
pointed out, many EXSLT extensions parallel pieces of XSLT 2 that are
missing from XSLT 1.  These pieces would clearly not be useful for an
XSLT 2-focused EXSLT effort.  What extensions would be useful?  I guess
I'd first try to look at things from an implementors point of view, and
I'd ask what XSLT 2 extensions currently exist in vendor
implementations.

I think that the EXSLT project will need a reorganization in order to
concurrently support (different sets of) extensions for XSLT 1 and XSLT
2.

Take care,

    John L. Clark

_______________________________________________
exslt mailing list
[email protected]
http://www.exslt.org/list

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.7 (GNU/Linux)

iD8DBQFD5N3+jkcskvOyl78RArTmAJwIwtvI5ciR1aIuy38XWyvWPP6nMQCfRlOH
OAZjOY+H/eeB2zCl2+uO3kI=
=Rx+8
-----END PGP SIGNATURE-----