Bug 4227 - QueryResourceProperites xpath dialect doesn't handle namespaces
: QueryResourceProperites xpath dialect doesn't handle namespaces
: Java WS Core
: 4.0.1
: All All
: P3 normal
: ---
Assigned To:
  Show dependency treegraph
Reported: 2006-02-20 13:39 by
Modified: 2006-07-21 15:34 (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2006-02-20 13:39:06
When using the xpath dialect for the QueryResourceProperties, there is no way
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

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"
<ns1:foo xmlns:ns1="http://example.com"/>

<ns1:TerminationTime xsi:nil="true"

<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)
------- Comment #1 From 2006-07-21 15:34:17 -------
Committed TargetedXPath query dialect implementation to trunk (provided by the
MDS team) that allows for a set of namespaces to be passed with the query.

Here's a bit more information on it: