easy question - empty element?

[Valery]

In the following XML:

<?xml version="1.0" encoding="utf-8" ?>
<Plcy service="ILiabi lity" boId ="LifePolicy , 1">
<Prem service="IPremi um" boId ="RegularPremiu m, 1"></Prem>
<L1 service="ILifeM ain" type = "Life1">
<FirstName>Shei la</FirstName>
<Age>65</Age>
<Relation>spous e</Relation>
</L1>
<L2 service="ILife" type = "Life2">
<FirstName>Bruc e</FirstName>
<Age>70</Age>
</L2>
</Plcy>

I would like to select Nodes with boId attribute which are empty. I am
using an XPath expression:

"//*[@boId and not(text())]"

but MS VS XPathNavigator' s Select() returns both Plcy and Prem. It
also sets IsEmpty field of Prem node to false.

Whose fault is it - mine or MS?

Yours,
Valery the Newbie

[Andy Dingley]

Re: easy question - empty element?

On 30 Oct, 08:53, Pavel Lepin <p.le...@ctncor p.comwrote:

Depending on what you mean by 'empty', you might actually
want one of the following:
>
//*[@boId and not(descendant: :text())]
//*[@boId and not(node())]
//*[@boId and not(text()[normalize-space()])]
//*[@boId and not(descendant: :text()[normalize-space()])]

I can't imagine many situations where "//*[...]" is a good idea,
especially not for an XPath newbie. That's going to match every
element in the tree, depending only on a complex predicate to filter
them. Predicates aren't easy to get right when you're starting out!

As you usually know the element name you're trying to match, it's
often going to be easier to match on the <policyor <premium>
elements with "policy [...]" or "premium [...]" and a simpler and more
reliable predicate.

I'd also advise using "policy [...]" rather than "//policy [...]",
unless you really need to. That "//" operation can be a nuisance too.

I'd also strongly recommend a more readable element named "<policy>"
rather than "<Plcy>". Abbreviating these names and introducing mixed-
case is just setting yourself up to make maintenance awkward in the
future and there's no benefit to doing it.

[Pavel Lepin]

Re: easy question - empty element?


Andy Dingley <dingbat@codesm iths.comwrote in
<1193746661.437 370.311060@k79g 2000hse.googleg roups.com>:

On 30 Oct, 08:53, Pavel Lepin <p.le...@ctncor p.comwrote:

>Depending on what you mean by 'empty', you might actually
>want one of the following:
>>
> //*[@boId and not(descendant: :text())]
> //*[@boId and not(node())]
> //*[@boId and not(text()[normalize-space()])]
> //*[@boId and
> not(descendant: :text()[normalize-space()])]

>
I can't imagine many situations where "//*[...]" is a good
idea, especially not for an XPath newbie.

There certainly are some. Processing meta-data stored in
attributes from a dedicated namespace seems to be one of
the more common use cases.

That's going to match every element in the tree, depending
only on a complex predicate to filter them.

Them's the breaks.

As you usually know the element name you're trying to
match...

Usually, but not necessarily.

I'd also strongly recommend a more readable element named
"<policy>" rather than "<Plcy>".

Agreed in principle, but in this case it took me all of a
quarter a second to parse 'Plcy'.

--
It is rare to find learned men who are clean, do not stink,
and have a sense of humour. -- Liselotte in a letter to
Sophie, 30 Jul 1705

[Andy Dingley]

Re: easy question - empty element?

On Tue, 30 Oct 2007 13:16:49 +0100, Martin Honnen <mahotrash@yaho o.de>
wrote:

>It does not check whether an element has no child nodes, rather it
>checks (or sets) whether an element is serialized as <element/or
><element></element>, for the former case it is true, for the latter it
>is false.

Ooh, nice ! A pseudo-DOM property that's tightly coupled to a minor
detail of serialization: that some child nodes (elements and text)
appear in one place, whilst other child nodes (attributes) don't.

What on earth is this thing _for_, and when is it ever going to be a
good idea to actually use the damned thing? Sometimes I wonder what
they're smoking in Redmond