A question about XPath filters (predicates)

[Altu]

Hi all,

What does something like [/a/b] mean in an XPath query like /c/d[/a/
b] ?

If I am not wrong, /c/d[./a/b] means return all d elements that their
parent is c and their grand parent is the root element and have a
child that is a and their a child has a child b. But I don't know when
we don't use an expression that starts with ./ or .// in a predicate
and instead use an epxression that starts with / or // what it would
mean.

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Thanks in advance.

 

[Johannes Koch]

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Yes, but the root is either c or a. So the XPath expression does not
select anything.

 

[Johannes Koch]

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Yes, but the root is either c or a.

I mean the root _element_.

 

[Altu]

Hi Johannes,

Thanks for the reply. Also what is the meaning of multiple consequtive
filters like

a[p1][p2][p2]

Does it mean a elements that satisfy p1 AND p2 and p3?

-Al

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Yes, but the root is either c or a.

I mean the root _element_.

So the XPath expression does not
select anything.

 

[Joe Kesselman]

Thanks for the reply. Also what is the meaning of multiple consequtive
filters like
a[p1][p2][p2]

Does it mean a elements that satisfy p1 AND p2 and p3?

Exactly. By the way, the proper term is "predicates", not filters.

 

[Richard Tobin]

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Yes, but the root is either c or a.

[/QUOTE]

The root node has exactly one element child, which is the root element.
You can only have /c/d if the root element is c, and [/a] will only
be true if the root element is a, so it will never succeed.

-- Richard

 

[Peter Flynn]

Hi all,

What does something like [/a/b] mean

It creates a dependency for the preceding object reference.
In this case it specifies that there must exist an element b which is a
child of the root element a. This condition will be applied to whatever
precedes the [/a/b] in the statement

in an XPath query like /c/d[/a/b] ?

This will return or process a child element d of the root element c
provided that a child element b exists of the root element a. As an XML
document can only have one root element, this condition can never be
satisfied, so the statement will always return null or false.

If I am not wrong, /c/d[./a/b] means return all d elements that their
parent is c and their grand parent is the root element and have a
child that is a and their a child has a child b.

That's not the query you posted at the start of your message.
The period introduces a change in scope, so that ./a/b now refers
to the structure you describe correctly.

But I don't know when
we don't use an expression that starts with ./ or .// in a predicate
and instead use an epxression that starts with / or // what it would
mean.

Exactly the same as you would when making a directory reference in a
typed command, eg
cd /var/www/html
rm -rf /home/peter
will delete all my personal files irrespective of my current directory.
cd /var/www/html
rm -rf ./home/peter
will delete any files in /var/www/html/home/peter

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Yes, which is an impossibility for the reason already given.

///Peter

 

[Altu]

Hi Peter,

Thanks for the reply.

The thing that was confusing me was that why would we insert a
predicate that starts with / or // in a specifiec location in the
XPath query. Looks like _generally_ they can be anywhere in the
query and yet we will get the same result.

So

//a/b/*/c//d[/a/b/d][/a//b/g][/a/b//g] is equal to
//a[/a/b/d]/b[/a//b/g]/*/c//d[/a/b//g] is equal to
//a[/a/b/d][/a//b/g][/a/b//g]/b/*/c//d

with possible performance differences.

Regards,
Al

Hi all,

What does something like [/a/b] mean

It creates a dependency for the preceding object reference.
In this case it specifies that there must exist an element b which is a
child of the root element a. This condition will be applied to whatever
precedes the [/a/b] in the statement

in an XPath query like /c/d[/a/b] ?

This will return or process a child element d of the root element c
provided that a child element b exists of the root element a. As an XML
document can only have one root element, this condition can never be
satisfied, so the statement will always return null or false.

If I am not wrong, /c/d[./a/b] means return all d elements that their
parent is c and their grand parent is the root element and have a
child that is a and their a child has a child b.

That's not the query you posted at the start of your message.
The period introduces a change in scope, so that ./a/b now refers
to the structure you describe correctly.

But I don't know when
we don't use an expression that starts with ./ or .// in a predicate
and instead use an epxression that starts with / or // what it would
mean.

Exactly the same as you would when making a directory reference in a
typed command, eg
cd /var/www/html
rm -rf /home/peter
will delete all my personal files irrespective of my current directory.
cd /var/www/html
rm -rf ./home/peter
will delete any files in /var/www/html/home/peter

Does /c/d[/a], for example, mean return all d elements that have a
parent (c with a parent root) only if the root has a child a?

Yes, which is an impossibility for the reason already given.

///Peter

 

[Joe Kesselman]

The thing that was confusing me was that why would we insert a
predicate that starts with / or // in a specifiec location in the
XPath query

As with any programming language: There are multiple ways to solve
problems in XSLT. Generally, you should start by picking the one that
most directly expresses the operation you are trying to perform, unless
you know that there are performance reasons to do something else.

> //a/b/*/c//d[/a/b/d][/a//b/g][/a/b//g] is equal to
> //a[/a/b/d]/b[/a//b/g]/*/c//d[/a/b//g] is equal to
> //a[/a/b/d][/a//b/g][/a/b//g]/b/*/c//d

Yes, but absolute paths in predicates are a rare occurrance. Most
predicates will be local, relative tests of the specific element you're
looking at or its immediate surroundings, not a pointer off to some
not-obviously-related part of the document.

You've constructed a true statement, but not a particularly useful one.

 

[Peter Flynn]

Hi Peter,

Thanks for the reply.

The thing that was confusing me was that why would we insert a
predicate that starts with / or // in a specifiec location in the
XPath query. Looks like _generally_ they can be anywhere in the
query and yet we will get the same result.

A predicate which immediately references the root element can be
considered global in scope, in the sense that if it always evaluates to
false (as is the case with your example referencing a root element type
that could not exist), then the entire XPath statement which depends on
it will necessarily also always be false. In that case it is immaterial
where you place it in the expression.

Don't confuse syntax with logic. The XPath syntax permits you to express
constraints in a variety of ways in order to direct the expression to
reference the node that you want. Just because it allows something
doesn't mean that it will always be meaningful to express it that way.

The same applies in many languages: I can write "if(1==0)" or its
equivalent in most programming languages and it will be accepted for
compilation even though it will always evaluate to false.

The only occasion on which I tend to write a predicate which immediately
references the root element type is when I use it as a crude switch to
detect the current document type in XSLT which is common to several. So
for example in XSLT which handles DocBook, [/article] might enable a
certain XPath which would otherwise not be needed in books, etc. It's
inelegant and probably inefficient, and there are probably better
examples from other fields.

///Peter