Understanding XPath in XSLT

[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.le vel</FOO>
<BOO><FOO>foo.s econd.level</FOO></BOO>
<CHOO><BOO><FOO >foo.third.leve l</FOO></BOO></CHOO>

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

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

[Richard Tobin]

Re: Understanding XPath in XSLT

In article <bdad9de2.03120 20726.5ab2ef8c@ posting.google. com>,
tfsquare <tfsquare@yahoo .com> wrote:
[color=blue]
>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.[/color]

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
--
Spam filter: to mail me from a .com/.net site, put my surname in the headers.

FreeBSD rules!

[Toni Uusitalo]

Re: Understanding XPath in XSLT

Good xml (and related) tutorials can be found here:

http://www.zvon.org

(click tutorials and XPATH TUTORIAL for example)

with respect,
Toni Uusitalo

"tfsquare" <tfsquare@yahoo .com> wrote in message
news:bdad9de2.0 312020726.5ab2e f8c@posting.goo gle.com...[color=blue]
> All,
>
> I am new to XSLT and having some problems understanding the syntax of[/color]

[First Last]

Re: Understanding XPath in XSLT

Toni,
[color=blue][color=green]
>> Good xml (and related) tutorials can be found here:[/color][/color]
http://www.zvon.org<<

Thanks, I'll check that out.
TFSquare.



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[First Last]

Re: Understanding XPath in XSLT

Richard,

Thanks for the reply.
[color=blue][color=green]
>>An XML document can't contain three outer elements, so I'm surprised[/color][/color]
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

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Dimitre Novatchev]

Re: Understanding XPath in XSLT

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


"tfsquare" <tfsquare@yahoo .com> wrote in message
news:bdad9de2.0 312020726.5ab2e f8c@posting.goo gle.com...[color=blue]
> 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.le vel</FOO>
> <BOO><FOO>foo.s econd.level</FOO></BOO>
> <CHOO><BOO><FOO >foo.third.leve l</FOO></BOO></CHOO>
>
> My testing shows
> (a) "/*/FOO" results in a empty string
> (b) "//FOO" results in "foo.top.le vel"
> (c) "/FOO" results in a empty string
> (d) "//*/FOO" results in "foo.top.le vel"
> (e) "//*/*/FOO" results in "foo.top.le vel"
> (f) "//BOO/FOO" results in "foo.second.lev el"
>
> 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[/color]

[First Last]

Re: Understanding XPath in XSLT

Dimitre,
[color=blue][color=green]
>>http://fxsl.sourceforge.net/ -- the home of FXSL<<[/color][/color]

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

Thanks again,
TFSquare.



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Patrick TJ McPhee]

Re: Understanding XPath in XSLT

In article <3fcce5f5$0$883 82$75868355@new s.frii.net>,
First Last <tfsquare@yahoo .com> wrote:

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


--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

[Finnbarr P. Murphy]

Re: Understanding XPath in XSLT

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.

tfsquare@yahoo. com (tfsquare) wrote in message news:<bdad9de2. 0312020726.5ab2 ef8c@posting.go ogle.com>...
[color=blue]
> I'm hopelessly confused as to why various XPath's pick various nodes.
> Any help you can provide is greatly appreciated.
>[/color]

[Baldo]

Re: Understanding XPath in XSLT

tfsquare@yahoo. com (tfsquare) wrote in message news:<bdad9de2. 0312020726.5ab2 ef8c@posting.go ogle.com>...[color=blue]
> 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.le vel</FOO>
> <BOO><FOO>foo.s econd.level</FOO></BOO>
> <CHOO><BOO><FOO >foo.third.leve l</FOO></BOO></CHOO>[/color]

a main NODE is an "HAVE TO":

<ROOT>
<FOO>foo.top.le vel</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

[tfsquare]

Re: Understanding XPath in XSLT

Baldo,
[color=blue]
> a main NODE is an "HAVE TO":
>
> <ROOT>
> <FOO>foo.top.le vel</FOO>
> ....
> </ROOT>[/color]

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

[tfsquare]

Re: Understanding XPath in XSLT

Patrick,
[color=blue]
> 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.[/color]

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

[Baldo]

Re: Understanding XPath in XSLT

> When you say "HAVE TO" do you mean XSLT and/or XPath demands this,[color=blue]
> 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.[/color]

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

[Patrick TJ McPhee]

Re: Understanding XPath in XSLT

In article <bdad9de2.03120 40716.89aca73@p osting.google.c om>,
tfsquare <tfsquare@yahoo .com> wrote:
% Baldo,
%
% > a main NODE is an "HAVE TO":
% >
% > <ROOT>
% > <FOO>foo.top.le vel</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.
--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om