Re: [xsl] Clearing up XSL-speak

Subject: Re: [xsl] Clearing up XSL-speak
From: David Carlisle <davidc@xxxxxxxxx>
Date: Wed, 10 Dec 2003 10:24:50 GMT

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

Yes.

It bears some resemblance to the language under discussion (xslt) If we
talked about  "finding" nodes we'd have to say which xslt instructions
found things, and which did other things, whereas teh xslt instructions
that select  have the syntax select-... the analogy with English is
closer as well with select. for an Xpath like "/" you don't really need
to "search" or "find" the root node of your document, you know where it
is at the start, and it is handed to you as the initial node of the
transform, however before you do anything with it, you need to select it
with select="/" or specify code with a template that matches it with
match="/".


> 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?

That's the problem with making up your own terminoligy on the fly: you
have to decide such things and then explain them to others before they
know what you are talking about.


>  I would prefer it if people were more specific when
> referring to nodes: "attribute node", "element nodes", etc, r etc, rather than
> "element" or "attribute". 

XML documents have elements and attributes. XSLT/Xpath data is a tree of
nodes that more or less correspond to the original document. It is
sometimes helpful to elide the distinction and sometimes helpful to
stress it. Similar;y sometimes its helpful to stress "element node"
and sometimes its more convenient to talk of elements. Sometimes
(but rarely in an XSLT context it's convenient to talk of elementtags,
which is something else again.

> Sorry, that's an American thing--getting thrown a curve ball... 
Yes I could guess (although I have not seen the expression before)
But that was really my point. You are making assertions about
the use of unfamiliar and confusing terminology which I just don't think
hold up. When I looked at your message, just about the only terms in it
that I was sure I understood were the Xpath expressions. If you are
learning a new language then the terms are unfamiliar but that doesn't
mean the terms are wrong and should be changed.

> 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.

But it is a fact that the design of the language was explictly designed
to be reminiscent of the unix and windows file path. We could not tell
people that but we can't change history.


>  Unix. A lot of people don't use
> Unix--I use it by default on my Macintosh. Everyone can relate to a
> family-tree,

Much of the terminology comes from family trees; child::
following-sibling:: ancestor:: etc, however the syntax /a/b/*
is just lifted straight from the shell file path syntax.

> 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.
Yes this is true (If you mean what I think you mean) 
A single Xpath expression (as it selects a set of nodes, not just one)
can represent many actual paths (branches) in the document tree.

> Eh? Five types of what? See what I mean, now you've confused me again! :P
not types of anything, just types.
Xpath has the types
number node boolean string 
XSLT adds result tree fragment,
so that's 5 in all (plus one special object type for encapsulating any
non standard extensions that a system might have)

> Because we are "selecting and matching" I find it hard to understand where
> I/O fits into this.

If you start off with a document <x/> and transform it with
<xsl:template match="x">
<y/>
</xsl:template>
then the first document <x/> is the input document and the result
document <y/> is the result document. Exactly how the system does I/O
is out of scope for the spec itself, but every system gives you some way
of getting hold of the result, otherwise what's the point?

> Can you see my point about "rewriting" the
> way for the "next wave"? 

No. It seems you found an example  where someone used a term not closely
aligned with the terms in the actual specification which meant that
without beeing given more context it's hard to be sure what exactly was
meant. However you are arguing that technical terms be used less not
more.

> Is XSL a "declarative" language?
I don't know what that means.


Roughly speaking it means that you declare what you want the result to
be, not specify exactly how what the machine does to do it. "imperative"
languags consist of instructions executed sequentially (mostly) by a
machine. 

> To me, XSL is more like a glorified search function than a
>language. Or rather, "the little search function that could".

Xpath is a search function, itjust searches (and selects) nodes in a
tree or trees, XSLt is a programming language, you can express any
algorithm in xslt that you can express in any other language.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

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


Current Thread