Re: [xsl] RE: Are there things missing in XSLT which force people to use, say, Java to process XML?

Subject: Re: [xsl] RE: Are there things missing in XSLT which force people to use, say, Java to process XML?
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 29 Oct 2010 16:43:41 -0400
At 2010-10-29 15:59 -0400, Costello, Roger L. wrote:
I recently saw the following assertions. Can you help me refute them please:

(1) XSLT is a complete programming language, but doesn't support
    most things most developers need to do.  (Graphics, networking,
    relational database access, parsing HTTP headers, generating RSS
    feeds, peer-to-peer networking, memory management & caching, thread
    management, MIDI programming, the list goes on and on and on).

Horses for courses.


Developers can do those cited things that XSLT doesn't do with tools that are designed to work with those cited things. XSLT is good for accessing structured information in order to rearrange it and augment it into a new arrangement of structured information. What that is the task a developer needs to do, then XSLT is that developer's best technology. When the task is something else, use whatever else is best for that task.

(2) Java (and others) were also designed to be enterprise-class programming
languages. This means the assumption that many programmers will collaborate
around a large project. Encapsulation and complexity hiding are very important.
A strongly typed, compiled language (not interpreted) is also important.
In short, XSLT wasn't designed for "programming in the large".

XSLT absolutely was designed for "programming in the large", even more so than XQuery, because of the flexibility of being able to import and include modules. Different members of the team can work on modules independently. Modules can be checked in to source code control systems and referenced by other team members.


Encapsulation and complexity hiding are well supported through the use of namespace-qualified global named constructs (something available since 1999 but rarely used). This practice is incredibly important when deploying a large project.

A global variable in XSLT has global visibility in every module in the import/include chain, even those introduced after the import/include chain is written and imported/included by the new module. This supports last-minute changes without touching a (perhaps read-only) production module by importing the read-only module and overriding behaviours.

XPath 2 supports many very useful data types.

That I can deploy a stylesheet in a shop to be exploited by other team members without needing to modify it before they can do so is incredibly powerful.

I see nothing in your short list for "programming in the large" that is not available in XSLT: large teams, encapsulation, complexity hiding.

I don't agree with criticisms over compiled/interpreted code ... once we start seeing massively-parallelized implementations of XSLT/XQuery/XPath processors, we'll quickly be grinding through XML content a lot faster than a Java program. XSLT and XQuery side-effect-free syntax inherently supports parallelism. XPath's node hierarchy inherently supports parallelism.

Furthermore (and I don't see this in your http://xsl.markmail.org/message/p53u3zfbrj2tt62m list of Java programmers not using XSLT) is that Java programmers are not used to treating XML as a first-class data construct or treating XML syntax as part of the programming language syntax. When working with XML, treating that XML with an XML-based tool makes sense. Treating it as a second-class citizen using subroutines within Java and without any XML syntax in the Java expression imposes overheads on the programmer when needing to deal with XML. I think that gives XSLT/XQuery the edge in programming when working with XML.

I hope this helps.

. . . . . . . . . . . Ken

--
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/s/
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/s/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Current Thread