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