[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: xslt core and intuition was RE: Reference to varia

Subject: Re: xslt core and intuition was RE: Reference to variable cannot be resolved.
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Fri, 14 Feb 2003 13:46:11 -0500
xslt core
At 06:37 AM 2/14/2003, bryan wrote:
Here is something I wonder about as I don't know that my own experience
is something to go by:
What do people think is a required level of understanding (the core) of
xslt beyond which one can intuit the rest.

The data model and XPath. The processing model, templates, and "document-driven" ("push") processing: how it works, why it's good, and when it doesn't help and you have to try something else.


If you get these, the rest can follow. If you try to fake it and write XSLT without understanding these, you'll get into trouble, probably sooner rather than later.

And how much of xslt do people think can be intuited.

In my experience (learning and teaching) what makes XSLT hard is not XSLT so much as it's the interference of preconceptions about the way "computers" or "computer languages" work or "should" work. Comparatively unburdened by years of experience writing procedural code, I've never found XSLT particularly difficult, apart from a short list of "gotchas". (Well okay, I've written code before, I'm not an absolute tyro; but still, the only people who'd consider me a "computer programmer" are not themselves programmers. What this essentially boils down to is that I'm untroubled when someone like David says "hey, it's not like what BASIC, Fortran or Javascript calls a 'variable'; it's more like a variable in algebra". For whatever reason, others seem to resist this.)


Likewise, I have taught hands-on classes in which the neophytes who'd never done anything beyond HTML have done great, while the code jockeys sitting next to them have been pulling out their hair.

Particular problems in XSLT have been difficult; but this has had more to do with the problems, and sometimes the poor fit between the problem and what XSLT does well, not with XSLT as such.

One reason XSLT seems especially mysterious, I think, is because people think of a stylesheet as a "program" that gets "executed". It's not: it's just a *specification* for a transformation, and rightly should contain the minimum possible programming logic. Mike Kay (or the guys at IBM, or MS, or your other friendly XSLT engine developer) wrote the program; I'm just running their code with my inputs. (And yes, I know this is not an absolute distinction. ;-)

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 ======================================================================


XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.