Understanding XPath in XSLT

T

tfsquare

All,

I am new to XSLT and having some problems understanding the syntax of
XPath which selects nodes in the XML document. Consider this bit of
XML, which contains three outer XML elements.

<FOO>foo.top.level</FOO>
<BOO><FOO>foo.second.level</FOO></BOO>
<CHOO><BOO><FOO>foo.third.level</FOO></BOO></CHOO>

My testing shows
(a) "/*/FOO" results in a empty string
(b) "//FOO" results in "foo.top.level"
(c) "/FOO" results in a empty string
(d) "//*/FOO" results in "foo.top.level"
(e) "//*/*/FOO" results in "foo.top.level"
(f) "//BOO/FOO" results in "foo.second.level"

I'm picking up the results like this...

<xsl:variable name="foo1" select="/*/FOO"/>

I'm hopelessly confused as to why various XPath's pick various nodes.
Any help you can provide is greatly appreciated.

Thanks,
TFSquare
 
R

Richard Tobin

tfsquare said:
I am new to XSLT and having some problems understanding the syntax of
XPath which selects nodes in the XML document. Consider this bit of
XML, which contains three outer XML elements.

An XML document can't contain three outer elements, so I'm surprised
you're not getting an error. What exactly are you doing?

-- Richard
 
F

First Last

Richard,

Thanks for the reply.
you're not getting an error. What exactly are you doing?<<

True, but XSLT can process a stream of 'multiple XML documents'. Here
is a quote from Michael Kay's XSLT 2nd Edition, page 358.

"If you are writing a stylesheet that loads several source douments
using the document() function, there is no direct way of selecting *the
root of the principal source document* when the context node is a
different one."

The fog is slowly clearing as I read more and try various XPath's to see
what they do, but I've got a ways to go yet. In my example, I now see
part of the problem was the "context" node was set to a place I hadn't
expected.

In regards to your question: What exactly am I doing? I'm processing a
stream of mini-XML documents (I think of them as small objects) to
through a XSL stylesheet to produce HTML output.

Thanks,
TFSquare
 
D

Dimitre Novatchev

A good book on XPath will help. I can also recommend the XPath Visualizer --
a tool that helps learn XPath through many practical exercises and in a fun
way.


=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL
 
F

First Last

Dimitre,

I'm reading this right now -- this is very helpful.

Thanks again,
TFSquare.
 
P

Patrick TJ McPhee

% In regards to your question: What exactly am I doing? I'm processing a
% stream of mini-XML documents (I think of them as small objects) to
% through a XSL stylesheet to produce HTML output.

That's vaguely what you're doing. We're all curious to know
_exactly_ what you're doing. i.e., show us some XSLT or we'll
be losing sleep from wondering.
 
F

Finnbarr P. Murphy

Have a look at Dimitre Novatchev's XPath Visualizer tool which
is available at www.vbxml.com/xpathvisualizer/default.asp
It's a good easy-to-use (and free) tool for learning the nuances
of XPath.

- Finnbarr

This is a full blown Visual XPath Interpreter for the evaluation of
any XPath expression
and visual presentation of the resulting nodeset or scalar value.
 
B

Baldo

All,

I am new to XSLT and having some problems understanding the syntax of
XPath which selects nodes in the XML document. Consider this bit of
XML, which contains three outer XML elements.

<FOO>foo.top.level</FOO>
<BOO><FOO>foo.second.level</FOO></BOO>
<CHOO><BOO><FOO>foo.third.level</FOO></BOO></CHOO>

a main NODE is an "HAVE TO":

<ROOT>
<FOO>foo.top.level</FOO>
<BOO>
<FOO>foo.second.level</FOO>
</BOO>
<CHOO>
<BOO>
<FOO>foo.third.level</FOO>
</BOO>
</CHOO>
</ROOT>

select="root/foo" --> top
select="root/boo/foo" --> second
select="root/choo/boo/foo" --> third

select="//foo" --> top, second, third
 
T

tfsquare

Baldo,
a main NODE is an "HAVE TO":

<ROOT>
<FOO>foo.top.level</FOO>
....
</ROOT>

When you say "HAVE TO" do you mean XSLT and/or XPath demands this,
perhaps as specified in a RFC? That would be interesting. Of course
my problem is trying to understand existing XPaths in the context of
existing XSL, XML and XPath expressions.

Thanks,
TFSquare
 
T

tfsquare

Patrick,
That's vaguely what you're doing. We're all curious to know
_exactly_ what you're doing. i.e., show us some XSLT or we'll
be losing sleep from wondering.

No, no, if I posted _exactly_ what I'm doing, THAT would keep you up
at night, I know it does me :)
 
B

Baldo

When you say "HAVE TO" do you mean XSLT and/or XPath demands this,
perhaps as specified in a RFC? That would be interesting. Of course
my problem is trying to understand existing XPaths in the context of
existing XSL, XML and XPath expressions.

I think it's all about XML RFC.. try saving an XML file like that:

<root1>asd</root1>
<root2>asd</root2>

then open it with IE, NETSCAPE or OPERA (or any XML validator):

"XML parsing failed: junk after document element (Line: 2, Character:
0)

<root1>asd</root1>
<root2>asd</root2>"
--

If your problem is to understand existing XPaths in the context of
existing XML, you should test that XML is WELL FORMED..

Hope this is clear..
 
P

Patrick TJ McPhee

% Baldo,
%
% > a main NODE is an "HAVE TO":
% >
% > <ROOT>
% > <FOO>foo.top.level</FOO>
% > ....
% > </ROOT>
%
% When you say "HAVE TO" do you mean XSLT and/or XPath demands this,
% perhaps as specified in a RFC? That would be interesting. Of course

XML and related technologies are defined in w3c recommendations (and
oasis specifications) rather than RFCs. The most important XML recommendation
is `Extensible Markup Language (XML) 1.0', which you can find at

http://www.w3.org/TR/REC-xml

The most important concept described in that recommendation is
well-formedness. The rules for a well-formed document are reasonably
simple (this is taken from the second edition, but I don't think the
wording changed in the third edition):

[Definition: A textual object is a well-formed XML document if:]
1. Taken as a whole, it matches the production labeled document.
2. It meets all the well-formedness constraints given in this
specification.
3. Each of the parsed entities which is referenced directly
or indirectly within the document is well-formed.

I'm not going to quote the document production because it doesn't stand on
its own, but the recommendation explicitly states some implications of
matching it:

Matching the document production implies that:
1. It contains one or more elements.
2. [Definition: There is exactly one element, called the root,
or document element, no part of which appears in the content of
any other element.] For all other elements, if the start-tag is
in the content of another element, the end-tag is in the content
of the same element. More simply stated, the elements, delimited
by start- and end-tags, nest properly within each other.

[Definition: As a consequence of this, for each non-root element C in
the document, there is one other element P in the document such that C
is in the content of P, but is not in the content of any other element
that is in the content of P. P is referred to as the parent of C, and
C as a child of P.]

The second implication is what's meant by `HAVE TO'. If you have more
than one top-level element, you have more than one XML document.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,995
Messages
2,570,230
Members
46,817
Latest member
DicWeils

Latest Threads

Top