[GRAAP-WG] XPath issues in Creation Constraints

[Dominic Battre]

Hi Oliver,

I think I was not clear enough.

This is part of my SLA template:

<wsag:Location>//wsag:GuaranteeTerm[@wsag:Name='StageIn']/\
wsag:ServiceLevelObjective/wsag:CustomServiceLevel/\
assessgrid:ProvideStageInFilesBy</wsag:Location>

I can do something like

Location_Type location = ...; // get it from the java object
String xpath = location.getValue();

The problem is that xpath contains "wsag:" and "assessgrid:" which need
to be bound to the correct namespace and looked up in order to generate
your xquery expression:
   declare namespace wsag='what do I put here?'

Axis 1.x does not allow me to get all namespace bindings of the DOM node
that is represented by "location".

Chapter 4.2.5.1, 5.1.1 and Appendix 2 of the WS-Agreement spec use XPath
expressions instead of XQuery expressions as suggested by you.

So the problem is:

XPath expressions as in Appendix 2 may be impossible to evaluate with
current toolkits (I may be wrong, but the Globus Toolkit faced the same
problem). Alternatives would be to use XQuery as you indicated or the
TargetedXPath query that is used in the Globus Toolkit. I think it would
be a good idea to reflect such a proposal in the WS-Agreement spec. In
either way, I think that it would be necessary to specify the query
dialect used, which in my opinion is not possible at the moment.

This is common practice e.g. in WSRF:

http://docs.oasis-open.org/wsrf/wsrf-ws_resource_properties-1.2-spec-os.pdf
-> Section 5.4 (page 19)

Other parts of WS-Agreement have the same issue, that no dialect is
specified.

Best regards,

Dominic

Oliver Wäldrich wrote:
> Hi Dominic,
> 
> In the XMLBeans implementation you can declare the namespace prefix directly
> in the Xpath call. The Xpath expression we use are therefore constructed as
> follows:
> 
> 	declare namespace foo='http://bar.org'; $this/foo:bar
> 
> I did not find the place in the Xpath specification where the namespace
> declaration is defined, but 
> 
>   http://www.w3.org/TR/xquery-xpath-parsing/
> 
> indicates that this should be standard conform. However, this expressions
> work for XMLBeans. I think other implementations should support this as well
> (Saxon?).
> 
> Best regards,
> Oliver
> 
> -----Ursprüngliche Nachricht-----
> Von: graap-wg-bounces at ogf.org [mailto:graap-wg-bounces at ogf.org] Im Auftrag
> von Dominic Battre
> Gesendet: Donnerstag, 23. August 2007 00:05
> An: GRAAP-WG
> Betreff: [GRAAP-WG] XPath issues in Creation Constraints
> 
> 
> Hi.
> 
> As we are looking for interoperability tests and implementations start
> showing up, I have a question about common practice in the evaluation of
> creation constraints.
> 
> I have raised the issue before, but I think I have never received an answer.
> 
> The issue is:
> 
> A creation constraint might have an xpath "//wsag:foobar" but it is very
> difficult to get the namespace that is bound to the "wsag:" prefix. At least
> in case Axis 1 that is used.
> 
> Does Axis 2 solve this problem or any other toolkit? Otherwise the question
> is whether it is technically feasible to evaluate XPath expressions like
> that at all. If it is not feasible, it might be considered a problem in the
> WS-Agreement spec.
> 
> The reason for my writing this is that I found this bug report:
> http://bugzilla.globus.org/globus/show_bug.cgi?id=4227
> 
> The Globus Toolkit community faced the same issue and surrendered - or lets
> say, they came up with a very nice solution: Introducing a sane query
> language TargetedXPath.
> 
> This is the Schema:
> http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/schema/core/query/
> 
> This is the Implementation:
> http://src.gridindex.org/globus_4.1.1/xref/src/wsrf/java/core/source/src/org
> /globus/wsrf/query/targetedXPath/
> 
> I like this approach a lot. Would this be a viable approach for
> WS-Agreement?
> 
> Best regards,
> 
> Dominic
> --
>   graap-wg mailing list
>   graap-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/graap-wg
> 
>