Altova Mailing List Archives
>comp.text.xml Archive Home
>Thread Prev - Re: easy question - empty element?
>Thread Next - Re: easy question - empty element?
Re: easy question - empty element?
Date: 10/30/2007 4:25:00 PM
Andy Dingley <dingbat@c...> wrote in <1193746661.437370.311060@k...>: > On 30 Oct, 08:53, Pavel Lepin <p.le...@ctncorp.com> wrote: >> 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