Re: Status

> Wouldn't it be a great idea to not duplicate what XSL-T 2.0 already provides? <

While in general I can see this and your extended point ("don't duplicate, innovate" if I understand correctly) I also recognize the fact that there are a lot of folks would want a lot of what XPath 2.0 and XSLT 2.0 offer, they also recognize there are some areas that, from their standpoint, are unneccessary.  Whether anyone agrees or disagrees with their points, whats important to recognize is that there are a TON of folks who feel this way, and in most cases for the same reasons.

For version 1.0 of XSLT, the EXSLT effort was a GodSend, bringing a lot of functionality to the table that was neccessary.  With XSLT 2.0 there are very few missing pieces.  There are a few (Dimitre's exsl:memo-function *NEEDS* to be implemented, dynamic XPath evaluation still isn't part of the spec, but is implemented in EXSLT already so this is really a nil point, and a few more (would be interesting and necessary to compile a list of *ALL* proposed extensions to XPath 2.0 and XSLT 2.0 -- or does one already exist?)  But for the most part theres not a lot of value-add the EXSLT group could bring to the table *IN ADDITION* to whats already there.

With this in mind, it seems to me that any continued effort inside of the EXSLT namespace should be take the XSLT 2.0 Basic spec and streamline things, to then add the proposed compiled list from above, if they don't already exist.

The reason?

Well, there are several. The primary reason, the way I see it anyway, is that the folks behind efforts such as 4Suite for Python developers are more likely to develop XSLT 2.0-like features *IF* they feel that the value-add to Python developers is greater than what they can gain with existing Python libraries.  

Another reason is that I believe the folks who have developed EXSLT implementations for their 1.0 processors, but have yet to commit to a 2.0 processor, will be more likely to begin working on a streamlined EXSLT designed from a modified XSLT 2.0-Basic spec, knowing that they can do so in modules (read: they can implement and release one module at a time), and in the end have an understanding for what they would need to next to then take it a full XSLT 2.0-Basic implementation.

With this last point in mind, keeping the *EXACT* instruction elements and attribute names as they are specified in XSLT 2.0 I believe is a *NECESSARY* piece to ensure that the path from EXSLT to XSLT 2.0 is clean,  clear, and simple.

I *REALLY* like what John (L. Clark) is doing, and am excited to see what happens with his efforts.  I can tell you that from my personal standpoint several things are taking place in the background that will lead to *MUCH MORE* of my personal time to be made available for the development efforts of various projects.  While I can't go into deep detail just yet, this post from Dr. Kay (yep, He's blogging now! :) should help clue you into what I am refering to > http://saxonica.blogharbor.com/blog/_archives/2006/2/3/1743544.html <  My "guess" is that if Saxonica were to bring the Saxon.NET project under its wings, there will more than likely be a "Saxonica blessed" extended research project started up in which community members will be able to communicate, propose, and develop new ideas that could potentially find their way into an official Saxon/Saxon.NET release.  

Of course, I'm only "speculating" ;)

Viva le' [E]XSLT! :D


Frans Englich wrote:

>On Wednesday 01 February 2006 23:35, John L. Clark wrote:
>  
>
>>In order to take stock of where this project lies and perhaps infuse it
>>with some new energy, I started an ad-hoc status document[0] that
>>catalogs some of the outstanding issues that I believe ought to be
>>addressed by the community in some form.
>>
>>I think that we should spawn new threads on this list for any of the
>>individual topics raised in the article.  The article currently only
>>covers substantive issues, but I plan to extend it to procedural issues
>>in the near future.
>>    
>>
>
><quote>
>I know that several people have also expressed interest in a 
>method="exsl:xhtml".
></quote>
>
>XSL-T 2.0 has this..?
>
><quote>
>baseURI and documentURI (January, 2002) 
>These are extremely obvious (at least to me), and I'd like to get them in.
>
>EXSLT URI [Encoding] function proposals (August, 2003)
></quote>
>
>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 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.
>
>Personally, what I would like to see is strong specification of what the 
>extensions does, and a test suite. The XSL-T 2.0 WG is working on a test 
>suite, and perhaps that format can be re-used for specifying a future EXSL-T 
>test suite. On the other hand, perhaps I've gotten brain damaged by reading 
>F&O and the others..
>
>
>Cheers,
>
>		Frans
>_______________________________________________
>exslt mailing list
>[email protected]
>http://www.exslt.org/list
>
>
>
>  
>