commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Wannheden <>
Subject Re: [JXPath] unordered node-sets
Date Thu, 10 Feb 2005 08:58:04 GMT

Knut Wannheden <knut.wannheden <at>> writes:

> Dmitri Plotnikov <dmitri <at>> writes:
> > @name is a reserved attribute name for Java Objects.  It in fact checks the 
> > name of the property/key rather than the value of the property called 
> > "name". I think it is equivalent to "[name() = 'Foo'].  This feature should 
> > be deprecated, and I will try to do so in a future release.
> > 
> Yes, I think name() is indeed equivalent and IMO preferable as it's more XPath
> style and doesn't keep users from using @name to access an object's property
> "name" (i.e. getName()).
> In the JXPath based EMF search tool I've been working on
> ( I have now customized the JXPath axes as
> I've previously outlined (child:: and thus also descendant:: only for EMF
> containment references).  With this customization it is now very difficult to
> write queries which access the getName() method of an object.  Instead of
> "[@name = 'Foo']" I have to use something like "[string(@name) = 'Foo']".

If found a reasonable workaround for this which might be useful to others.  The
equality check can simply be turned around.  I.e. "['Foo' = @name]" works fine.

Now I've just got two more questions on this :-)  Have you been able to check if
removing DescendantContext#isChildOrderingRequired() breaks anything?  Do you
want me to open a feature request for either of these two changes?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message