On Tue, Mar 25, 2014 at 1:55 AM, David Rudel <fwqhgads(_at_)gmail(_dot_)com>
wrote:
On Tue, Mar 25, 2014 at 2:20 AM, Ihe Onwuka
<ihe(_dot_)onwuka(_at_)gmail(_dot_)com> wrote:
It's the whole premise of product design. If you got into a car for a
test drive you would have certain expectations about where certain
controls were and how certain things worked wouldn't you?. There
might be some special features that might explanation from the
salesman.
A false comparison, for XSLT has too many distinguishing features for
this analysis to work. If I climbed up on a tractor, I would be
naturally cautious to assume that everything worked the same as in my
Ford.
But this discussion is predicated on your Ford not your Tractor. It's
about Hello world.
If I got 10 programmers with 10 different backgrounds in a room and
asked them what they thought certain language constructs did - lets
say return() or an if statement, I am pretty sure there would be a
unanimity of expectation.
And they would also recognize that any construct [like an xpath path
expression] specific to the language might require specialized
knowledge. I bring this example up because it relates to your
recurring gripe about "text()." Since path expressions are not
ubiquitous to programming, I don't think it strains credulity to
expect a programmer to exercise caution when seeing something like
Joe/Bog/elephant/text() and recognizing that a quick primer on this
specialized topic may be necessary...and any such primer should point
out the notion of a "node test."
I come from a background that has read Allan Cooper's (About Face) and
Donald Norman's (Things that make us Smart).
Earlier today somebody posted that
In 99% text() is wrongly used, .....
Even allowing for exaggeration, to a person that has read Cooper and
Norman that stat says that the programmers are not the problem.
I don't see why a person who wants to extract 14 December 2014 from
<date>14 December 2014</date>
needs to know anything about a DOM or think in trees.
You don't have to think in trees, just like someone who wants to use
Java doesn't have to think in terms of objects... but it helps.
But, since you have come back to this example, I really must disagree
that executing such an operation requires some deep dive into the
spec.
One of the first things one learns in XSLT (from practically any
tutorial) is about default templates...
and once one knows how default
templates work, then immediately one knows that extracting the date
can be done simply by calling the node.
Well you not have had the experience delivering a training
presentation at a site with a legacy XSLT code base produced by 20 odd
programmers with nary a default template in it.
And I would claim that once someone is thinking in terms of trees and
nodes, then the "obvious" things to try work just fine in XSLT/Xpath.
OK. Not a human centric view. How can I illustrate.
How much do I have to know about a car and it's design if I just want
to drive it to work and back?
If a person buys a car with a manual transmission, it is incumbent
upon him to know what a clutch is.
I agree and they should also know what to expect when they engage it.
This is Hello World remember. Fords not tractors.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--