Re: [xsl] killing xslt

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

At 12:30 PM 5/13/2004, Oleg wrote:
> By the way, here is more detailed explanation - "Why You Won't See XSLT 
> 2.0 or XPath 2.0 in the Next Version of the .NET Framework" by Dare 
> Obasanjo, http://blogs.msdn.com/dareobasanjo/archive/2004/05/13/131166.aspx

This is strange. Its author is no dummy (as numerous other writings 
demonstrate), but his claim that XPath 2.0 (as opposed to XQuery) is weakly 
typed controverts every other description of it including its own (see 
XPath 2.0 WD of 12 November 2003, section 2.4: "XPath is a strongly typed 
language with a type system based on XML Schema..."). And then the argument:

> In the decision to go with XQuery over XSLT 2.0, Mark is right that we 
> felt that developers would prefer the familiar procedural model and syntax 
> of XQuery to the template based model and syntax of XSLT 2.0. Most 
> developers working with XSLT try to use it as a procedural language 
> anyway, and don't really harness the power of templates. There's always 
> the steep learning curve until you get to the "Aha" moment and everything 
> clicks. XQuery with its 
> <http://www.w3schools.com/xquery/xquery_flwor.asp>FLWOR construct and user 
> defined functions fits more naturally with how both programmers and 
> database administrators access and manipulate data than does XSLT 2.0. 
> Thus we feel XQuery and not XSLT is the future of XML based query and 
> transformation.

This seems to me not unlike Black & Decker saying "in our observation, 
carpenters have a hard time learning to use power tools, and can't use them 
well until they do learn, so we believe the future of carpentry is in hand 
tools". Maybe: but it may not be a good bet on the marketplace if thousands 
of carpenters worldwide are already using power tools quite happily to do 
things that are impossible or prohibitively difficult to do by hand. (It's 
also noteworthy that the author lumps "query and transformation" together 
as one thing.)

Who knows: maybe they can make us forget that we could ever do document 
processing with XSLT. Must repeat: "Data is for databases. Documents are 
for Word." :->

Cheers,
Wendell


======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================