[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|