This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
formal XSLT education (was Re: _why_ do people...)
- To: xsl-list at lists dot mulberrytech dot com
- Subject: [xsl] formal XSLT education (was Re: _why_ do people...)
- From: Mike Brown <mike at skew dot org>
- Date: Wed, 5 Sep 2001 16:38:16 -0600 (MDT)
- Reply-To: xsl-list at lists dot mulberrytech dot com
Deborah Aleyne Lapeyre wrote:
> What I don't see is the necessity of explaining literal result elements
> as a "shorthand" for anything. They are this, they do that, and nodes
> are written to the result tree, with this for a namespace. Beginners
> do not need complete stories, they need correct conceptual models.
Yes, you are right, and I don't think I implied that it was a necessity
to explain it as "shorthand", which I admit isn't entirely accurate.
Rather I was saying that it would potentially be a good way to reinforce
the correct understanding of the processing model and what literal result
elements actually are & do w.r.t. the result tree.
The where & why using one or the other, and the ramifications as far as
understanding namespace nodes and the significance of the XSLT namespace
URI, are more advanced topics that can be addressed and perhaps better
understood later.
> Controversially: I also think that the idea for "pull"
> (or fill-in-the-blank) stylesheets does not belong in the
> first day of a multi-day beginner class.
There is a bit of guesswork in knowing how much preparation your
students, or readers, if you write informative articles, have, and what
assumptions they are operating under. You want to steer them away from
common misconceptions and bad habits early, yet you don't want to immerse
them in intangible concepts for too long without providing code samples.
When I was writing my 'XML tutorial', I was trying to take the approach
that this is how I wish I could have learned XML, concepts first, syntax
and code samples last. But I have to admit that my first temptation when
explaining XSLT to someone is right off the bat to show them an XHTML
document containing
<xsl:value-of select="/path/to/data/in/an/xml/doc"/>,
which I think is pretty easy for the beginner to grasp, especially if
they've had any experience with PHP, ASP, Cold Fusion, etc.; and in fact I
operate under the assumption that this is where they are coming from, that
they are thinking in terms of these text-substitution oriented languages.
So I guess I am a bit conflicted as to the best way to steer people when
introducing them to XSLT. Is it better to start with a clean slate and
explain it all from the ground up, or do you make some assumptions about
what they already know and put effort into leading them from "the way you'd
think it would be done" to "the way it really gets done"?
- Mike
____________________________________________________________________________
mike j. brown, fourthought.com | xml/xslt: http://skew.org/xml/
denver/boulder, colorado, usa | personal: http://hyperreal.org/~mike/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list