Subject: RE: [xsl] XSLT vs Perl From: David.Pawson@xxxxxxxxxxx Date: Wed, 4 Feb 2004 09:57:54 -0000 |
On Tue, Feb 03, 2004 at 08:41:15PM -0000, Michael Kay wrote: > Yet we all know on this list that XSLT 1.0 has severe limitations. > It's very hard to do grouping, it's hard to do string manipulation, > it's hard to handle dates. > > We've provided facilities in 2.0 that greatly ease these problems. If XSLT 2.0 and XPath 2.0 stopped there, it would have been marvelous. Exactly!! Thanks Adam. [*] I'd like support in actually listing those 'real' improvements. I'll collate on the faq site if people send 'em to me/this list. But both of those specs integrate portions of XQuery and XML Schema that are really over the top. As it stands, XSLT 2.0 smells of second system syndrome. There are more creeping creatures in there than I can count. And understanding what all of those creatures do requires a huge investment in time, paper and effort. Which for many of us is a total waste of time. The WG claimed that 'customers' had requested the data typing. I don't recall any such requests on this list. There may have been some, but I'd guess its less than a hundred. One M$ employee claimed thousands of requests on the M$ list, maybe true I don't know. My guess its the datahead that wrote the requirement and the dataheads on the WG that drove XSLT into query land. By comparison, XSLT 1.0 required a good grasp of XPath 1.0 and a small number of XSLT element behaviors. Fewer interrelations, fewer techniques to master, and easier to apply than what I remember from the XSLT 2.0/XPath 2.0/XQuery 1.0/XML Schema 1.0/XML Schema Datatypes 1.0 stack. It has the same elegance/simplicity that xml has. > Therefore, if people preferred XSLT 1.0 over other languages when > performing these tasks, despite its shortcomings, they will certainly > prefer XSLT 2.0 over other languages. Actually, the way XSLT 2.0 is going, I'd much prefer XSLT 1.1 or 1.5: add the grouping and date handling, remove the nodeset/rtf distinction, and fix a couple of other warts in XSLT 1.0. *That* would be a killer language. And a couple of the functions? the tokenize() for instance? But yes, and it wouldn't have the 101 'implementation dependent' caveats that this spec is laden with. See [*] above. The situations that demand input/output validation and XQuery integration are totally separate domains. +1. regards DaveP. *** snip here *** regards DaveP - DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT vs Perl, bry | Thread | RE: [xsl] XSLT vs Perl, Willink, Ed |
RE: [xsl] Control DOCTYPE for HTML , Andrew Welch | Date | Re: [xsl] Switching off character e, David Carlisle |
Month |