Subject: Re: [wsbpel] Issue - 46 - Namespace for the document fragment representing a part
As the culprit behind the XPath stuff in BPEL 1.1, I'd like to weigh in on this. I was also on the XSLT WG where XPath 1.0 was defined. "Chris Keller" <firstname.lastname@example.org> writes: > Sorry if the wording of my replies misled you. My Issue is not really > about the part as type and property alias queries, but also XPath 1.0 > vs. XPath 2.0 and the queries within bpel assignments and expressions. > Even if we assume no namespaces in the document fragment under the part > as type case (which we should think hard about as validation would be an > issue), many of the messages would most definitely contain namespaces > and as such require qualification in XPath 1.0. XPath 1.0 does not require qualification unless the element/attribute itself is qualified. How else could it work?? What's the validation for unqualified stuff? I don't know of any myself. So as Ugo said, if the schema for the complex type that part/@type is referring to has qualified stuff, then stuff that follows /partname/.. would indeed be qualified. If not it would not be. That's it. Since we're still dealing with XPath 1.0 let's just focus on that and not worry about what XPath 2.0 does or says. In particular, I'm not qualified to debate that as I left the WG and haven't had the time to follow the specs. I'm sure there are more expert people here who can comment. W.r.t. the general issue of what namespaces are in scope for an XPath expression, XPath defines a notion of a context. So when evaluating an XPath expression the namespaces defined by the context are assumed to apply to the XPath expression as XPath itself has no way to define namespaces. In particular, in BPEL when you say "bpel:getContainerData()" say, the "bpel" prefix is resolved w.r.t. the namespaces visible on the element which contains an attribute whose value this expression is. So I don't think there is any issue whatsoever w.r.t. the namespaces of part names or any other name used in any XPath expression in BPEL. I'm not sure whether the spec clearly says how the XPath context should be computed (IIRC something was added to clarify that) but there's only one meaningful way to do it (see above paragraph) IMO. Bye, Sanjiva.