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@ogf.org [mailto:graap-wg-bounces@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@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg