[xsl] Clearing up XSL-speak

Subject: [xsl] Clearing up XSL-speak
From: JCS <subscriber@xxxxxxxxxxxxx>
Date: Wed, 10 Dec 2003 19:22:26 +1300
This thread has changed topic, thus the new subject head.

On 10/12/03 2:26 PM, "David Carlisle" <davidc@xxxxxxxxx> wrote:

>> Yes, using the former <xsl:for-each select="//*[not(*)]"> per David's
>> suggestion did the trick. I wouldn't have thought of this--something that
>> would elude the beginner I think. This is saying to me, "select each child
>> that doesn't have any children." I think that's a simple way of putting it,
>> right?
> Almost. select each descendant element  that does not have a child element.

Okay, right. Is there a difference between using the word "select" and the
word "find?"

Could I say:

Select each descendant _element node_ that does not have a child _element


Find each descendant _element node_ that does not have a child _element

Should it always be the word "select?" I ask because I understand there is a
difference between "matching" and "selecting". "Find" may be too ambiguous
and may imply either?

> *[not(*)] would select each child that doesn't have a child (ie it would
> only look one generation down) it's // that forces the full depth
> descendant axis to be used.
> the child axis includes text nodes comments and PIs as well as elements
> so "no child" would be not(node()) rather than not(*), which you want
> depends on which of these you think has a child
> <x>a</x>
> <x><!--a--></x>
> <x/>

Node() means "all nodes," correct? If you notice I've appended the suffix
_node to element above to get element_node. This is something I was thinking
about today--that which adds to my confusion is that XSL terms are used
loosely. Because this is new to me, it's still hard to think of an element
as an "element node" because my head wants to encapsulate all other nodes
into the element node! I would prefer it if people were more specific when
referring to nodes: "attribute node", "element nodes", etc, rather than
"element" or "attribute". Why? So when the term node() pops up in
conversation, my mind gathers all the node types together quite easily. It
helps me draw _relationships_. Others learning XSL would find this
beneficial as well. Because when people start talking "nodes," without that
_node_ suffix used to anchor the types of nodes in people's heads, an
element is an element. It's NOT a node. Does that make sense?

In teaching, to throw out these terms (element, attribute, text, etc.)
without anchoring them just leads to confusion when one asks "what's a
node?" And then the reply is "There are five of them," suddenly another
neural connection has to be made. Better for the powers at large to *always*
reference nodes by name--not loosely, IMO.

>> I guess what I'm suggesting is that a
>> possible explanation for an XPath path is that it is selected by node
>> relationships, not by node routes. A path implies an arbitrary route,
>> whereas the word relationship triggers the concept of "connections". Even a
>> bus route is arbitrary unless you know where it "stops" i.e. Know how it is
>> connected.
> you lost me there (actually you lost me at "curve ball" this is
> presumably a sporting analogy, but I'm not sure if having curved balls
> is good or bad, sounds good, compared to having square wheels, which is
> usually considered bad)

Sorry, that's an American thing--getting thrown a curve ball... Taken
off-guard, etc. What I'm saying is that it's may be easier to describe an
XPath from a relational POV based on a family-tree hierarchy rather than
consider it to be like a directory path in Unix. A lot of people don't use
Unix--I use it by default on my Macintosh. Everyone can relate to a
family-tree, not many will understand what a directory path is, even if
they've used one before. Since the path refers to child/parent
relationships, etc, I think it's better to keep the analogies consistent. It
will be obvious to those who deal with directories that the XPath is "like"
a directory. Those who don't know anything about directory structures are
now faced with a more complex problems: what is XPath because I'm being told
it's like a directory. And frankly, it's NOT really like a directory--unless
you can Mod Rewrite an XPath query using it as an analogy should be
discouraged. It's similar, but not the same. I can't put "wildcard" searches
in a directory path in Apache, can I?

>> The path then becomes incidental.
> I'm still lost. How can a path be incidental in an Xpath?
> I'm all for a simplifying explanation if one can be found, but I find
> this suggested terminology baffling (whereas the usual Xpath
> terminology, and Xpath itself is fairly natural to anyone who's used a
> filepath  on a unix or windows/dos file system, or a URL.)

By incidental, I mean that if one looks at the XPath as "not a path" but a
series of relationships that _build_ a path, the path is simply a by-product
of those relationships.

For example, you have a child. We can assume that the child *must* have a
parent. We have an descendant. We can assume that the descendant *must* have
ancestors. So if I tell a ten-year old to "build me a path to Grandmas
house" we've got room for interpretation. From where? Where exactly is
Grandmas house? How _do_ I get there from here?

However, if I say "Show me all of Grandmas children," then it's pretty easy
to perhaps draw a diagram showing Grandma and her children. The path itself
is created as a by-product--it's incidental. What's more important is
understanding the relationship, because it's what _built_ the path (The line
drawn from Grandma to her children). Hopefully that makes sense.

"Give a man to fish, feed him for a day, teach a man to fish, feed him for

One of the problems I have with teaching solutions is that they're not
always geared towards teaching me how to fish. Usually they just want to
give me the fish and be done with it. This is why I frequently bring up the
concept of teaching a ten-year old literate child. If you want to know if
something makes sense, explain it to a curious ten-year old. If he's
confused, go back to the drawing board and find a better explanation.

The following is from a "tutorial" I found on the net explaining the select


The following query finds 'author' elements with a 'period' attribute whose
value is 'classical' and that are contained in the 'authors' element at the
document root. 



This very type of statement is very common in XSL tutorials. I wouldn't
expect anyone new to XSL to understand this on the first pass. There are too
many relationships being defined in one sentence. It needs to be broken down
into something more digestible. That statement is trying to give me a fish.
It doesn't show me *how* to construct my own query. But it could.

The following may "teach" me how to fish:


Which means:

In steps, the following relationships create a path which will select a node

/authors =  
find the element_node "authors" which is the child of root
find the element_node "author" which is the child of "authors"

find the attribute_node "period" with the value "classical" which belongs to

But that may not be correct. Please check that. But it's presented in a more
"procedural" manor. Notice I've used "find" not "select". Is this
acceptable? Also, note I've added the suffix "node" where appropriate, to
anchor the term "node" in the mind, which should *always* be done when
talking XSL, IMO. 

>> Sometimes I think I'm in a room full of lawyers with all the jargon that's
>> thrown around a conversation--inconsistently. "node sets", "fragment trees",
> Xpath only has five types, and that's 2 of them, 5 is rather few types
> in most programming languages (Xpath2 has about 1050, as they have just
> inflicted schema typing on it) Would you expect a list devoted to Java
> never to mention a double, or a class or any other words for java
> constructs?

Eh? Five types of what? See what I mean, now you've confused me again! :P

>> "matching vs. selecting"
> I don't see how you can discuss xslt without that.
> Just about every xslt expression has either a selcet= attribute or a
> match= attribute. We could call it "a" and "b" if you don't like those
> words but then how would youknow whether template match="xxx" was of
> type "a" or type "b", The words used to describe the language have to
> bear at least _some_ resemblance to the language constructs.

No, I agree. I brought this up because the differentiation is not clear in
tutorials I come across. Is matching different than selecting? I think so,
but I'm not sure exactly what the differences are. This should be an easy
find when learning XSL--it's not.
>> , "result tree", "input",
> Most programs have an input and an output, how can you avoid mentioning
> that?

I'm not suggesting avoiding it. I'm suggesting that "input" and "output"
confuses me in a "transform" setting. Anyone that knows procedural language
or BASIC started off with INPUT=$NAME which usually refers to a form of
sorts, yes? So is input the XML document? What is the output? The document?
Because we are "selecting and matching" I find it hard to understand where
I/O fits into this. What I mean is, it's not simple enough to understand.

>> "node structures"...
> this isn't a term I see used. But I would assume it means node tree.

Ah, see? That's an actual term I saw used somewhere. I'm sure if I wanted to
I could find it somewhere. But to a beginner, making assumptions leads to
serious frustration and error. Can you see my point about "rewriting" the
way for the "next wave"? I think people are interpreting too much when it
comes to XSL terminology because it wrapped in itself--what I mean is that
it's not explained in a way people can digest it easily. You're either in it
or your not, and people are trying to cross-over using their own references
to XSL terms.

>> And most of the terminology is counterintuitive.
> Like all languages it has some idioms that are not particularly
> intuitive using keys for grouping is a particular;y spectacular example,
> it's fairly simple and can give orders of magnitude speed improvements
> over more natural expressions but it could not by any stretch of the
> imagination be called an intuitive (the technique is usually known as
> muenchian grouping around here in honour of the person who thought of
> it) but I would not class any of the items you mentioned in this
> category, they are the names of the basic constructs in the language.

Actually, I find keys one of the easiest concepts to grasp from my SQL
knowledge. Using them properly is another thing, but understanding them was
a piece of cake. It's the XPath queries and how templates interact with each
other that takes a bit of playing around with to become somewhat comfortable
with the language, but even saying that it's still very hard to program in
XSL because using the same logic I would in PHP, for example,  doesn't apply
here, where it might in ASP or even C++. Is XSL a "declarative" language? I
saw Jeni make that statement somewhere. I don't know what that means.

>> It's bad enough that one
>> must "unlearn" previous programming logic to embrace XSL.
> That of course depends on your previous programming experience.
> Not everyone has a java background, and the functional programming
> paradigm of which xslt is part has a much longer history than the OO
> programming paradigm that Java uses. It's perhaps less popular at the
> moment. People who haven't programmed much before tend to pick up xslt
> fairly quickly, java programmers find it harder as they have strange
> expectations like variables changing their value.

I agree, and this is why XSL is always throwing me those "curve balls"
because what makes sense in PHP/ASP/C++/Java, or even BASIC, isn't really
happening here. To me, XSL is more like a glorified search function than a
language. Or rather, "the little search function that could".

/johnny :)

There are no blueprints for friendships, each one is custom made.
-- Robert Scotellaro 

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

Current Thread