When using the xpath dialect for the QueryResourceProperties, there is no way
to
express the namespace prefixes, yet the implementation of the dialect
(org.globus.wsrf.impl.XPathExpressionEvaluator) is not agnostic to prefixes, it
just assigns prefixes arbitrarily by reading the contents of the target
ResourcePropertySet.

The implementation seems to blame this on the specification (lines 115-126):
        // Turn ResourcePropertySet into one big DOM element
        Element rootElement = resourcePropertySet.toElement();

        // collects all NS in the document and puts them in the root element
        // that root element is then used for xpath query to resolve all
        // namespaces defined in the xpath query.

        // XXX: The namespaces should probably be somehow passed with the query
        // this will require spec changes
        Map namespaces = new HashMap();
        collectNamespaces(rootElement, namespaces, new HashMap());
        setNamespaces(rootElement, namespaces);

This approach doesn't work as expect from a client, as prefixes that are not
defined in the target document can be used to query it.  Take for example the
following queries to a service with two resource properties:

/*/*
<ns1:TerminationTime xsi:nil="true"
xmlns:ns1="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<ns1:foo xmlns:ns1="http://example.com"/>

/*/ns1:*
<ns1:TerminationTime xsi:nil="true"
xmlns:ns1="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>

/*/ns2:*
<ns1:foo xmlns:ns1="http://example.com"/>

In this example, the prefix ns1 is (legally) used in the ResourcePropertSet to
refer to two different namespaces, yet when the implementation code aggregates
all of the document's namespaces to a single set, it must change the second one
to ns2 to maintain uniqueness.  This results in client query using a completely
undefined namespace prefix (/*/ns2:*) returning indeterminate results (without
reading the implementation code).

While this behavior is undesirable, the real problem is the lack of capability
of the client to express and use its own namespace prefixes.  Implementing this
correctly does not require a specification change, it simply requires further
definition on what is expected from the dialect's query value.  An appropriate
solution would be to define an element the allowed the definition of 0...*
namespace to prefix mapping elements, followed by an element containing the
actual query.

This change represents a loss of functionality from Globus 3.x, as namespace
mappings were properly handled in previous releases.

This issue should be resolved by either:
1) implementing a dialect query value as stated above
or less desirably
2) the implementation should not allow use of namespace prefixes in the query
(as they are ambiguous in the query context)