RE: [xsl] XSLT vs Perl

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