Subject: Re: [xsl] libxslt version changes RTF or exsl node-set sorting behavior From: Daniel Veillard <daniel@xxxxxxxxxxxx> Date: Sat, 31 Jan 2004 23:45:53 +0100 |
On Sat, Jan 31, 2004 at 05:50:22PM -0000, Michael Kay wrote: > > My experience is that node-set() is a badly broken > > extension to XSLT-1.0 > > I think that describing an extension as broken because you have > difficulty implementing it using your chosen implementation technology > is a little unreasonable. Well the Working Group differenciated Result Value Tree from the node set when producing XSLT-1.0 . It was guided by implementation issues IMHO, from that perspective node-set() runs againts that decision, and even worse allowing RVT to be directly usable where it shouldn't really confused people. That is where the people started to expect this to work on XSLT processors, develop algorithms based on this and considering this a "feature" of the language. I think I did complain clearly and directly about this, but that was an implementation issue, so I complained here and not in the XSLT-1.0 spec comment list because well it wasn't really an XSLT-1.0 problem. > I was not aware before now that anyone opposed this facility. I'm > surprised that if you object to it so strongly, you haven't made your > views known until now. Given that there are many successful Ohhh I think it's not the first time I complain about it :-) > implementations, I don't think the working group would be greatly swayed > by an argument based on implementability; but there have been other > features (like xx:evaluate()) excluded on similar grounds and you should > at least try to make your views known at the right time in the right > place. Well arguing w.r.t. XSLT-1.0 is useless because node-set() is not in that spec. Arguing against 1.1, I did a long time ago and had to wait months and months before the deprecated Working Draft finally got flagged as such, at the time I was on the W3C XML CG ! W.r.t. XSLT-2.0 there is more issues than simply node-set(), implementation are anyway very different and expecting to keep 1.0 design issues isn't technically sound, XSLT-2.0 will be reimplementations not simple evolutions so complaining about node-set() being a big change in comparison to XSLT-1.0 implementation design makes little sense anyway. I stated my view on 2.0 on this list and I think I CC'ed the comment list at the time, but it was useless to point at node-set() specifically. Finally I don't see myself argue against EXSLT:node-set(), it's clearly an extension, so the "XSLT-1.0 compatibility" viewpoint can't really hold. I think I did made my views known at the right time and in the right places, i.e. where that made sense. I think I also complained to Sharon and you at the time when Saxon used liberally RVT as node-set inputs. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] libxslt version changes R, Michael Kay | Thread | Re: [xsl] libxslt version changes R, David Tolpin |
RE: [xsl] libxslt version changes R, Michael Kay | Date | Re: [xsl] libxslt version changes R, David Tolpin |
Month |