Cart
[Home] [By Thread] [By Date] [Recent Entries]
At 2010-10-29 15:59 -0400, Costello, Roger L. wrote:
I recently saw the following assertions. Can you help me refute them please: 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 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
|
