[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] XSLT Hello World

---

---

On Tue, Mar 25, 2014 at 1:55 AM, David Rudel <fwqhgads@xxxxxxxxx> wrote:
> On Tue, Mar 25, 2014 at 2:20 AM, Ihe Onwuka <ihe.onwuka@xxxxxxxxx> 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.

---