Re: [wsbpel] Issue - 46 - Namespace for the document fragment representing a part

["Sanjiva Weerawarana" <sanjiva@watson.ibm.com>]

Hi Chris,

Yep, I agree- more examples are needed and definitely more clarity
on how the namespace resolution for QNames within XPaths in BPEL
must be done has to be better explained. If that's the resolution
for this issue I'm happy too!

I do realize the query + assign stuff makes it possible to do some
screwy things that could make the result invalid. I think that's
the issue Yaron has raised (#11?). I personally don't think there's
much that can be done about it given the richness of schema (for
example, one may assign stuff inside an element and then maybe that
element itself never appears .. then what), but I certainly appreciate
people trying to be more rigourous about it.

Sanjiva.

----- Original Message -----
From: "Chris Keller" <chris.keller@active-endpoints.com>
To: "'Sanjiva Weerawarana'" <sanjiva@watson.ibm.com>; "'Ugo Corda'"
<UCorda@SeeBeyond.com>; <wsbpel@lists.oasis-open.org>
Cc: "'David RR Webber - XML ebusiness'" <Gnosis_@compuserve.com>
Sent: Friday, August 08, 2003 9:10 AM
Subject: RE: [wsbpel] Issue - 46 - Namespace for the document fragment
representing a part


> Sanjiva,
>
> Thanks for chiming in.
>
> I believe, for clarity, we need more examples.  It may be clear to the
> experts how a bpel engine should reconstitute a document fragment when
> it is transmitted in any binding.  However I am not sure it is clear to
> everyone else.  Let's make sure it is clear so that the queries that
> user's write will not result in failures based on the engine they are
> using or the partner's binding they are dealing with.  IMO we need to
> spell it out with examples or we will end up with problems.  There are
> too few examples of query usage given how heavily people will rely on
> queries.
>
> The other issue with these document fragments being reconstituted from
> any binding is that they can be modified by assign activities.  If we
> aren't careful it will be difficult to validate these modified
> fragments.
>
> In summary if the only outcome of this issue is that we add a few more
> examples. And state precisely what a part/query context is (for both
> part as type and part as element) so that it is unambiguous under any
> binding (as bpel is binding independent).  Plus as a real nice to have
> make sure that the resulting parts can be validated even after use
> within a <to> assign.  Then it was worth raising the issue.
>
> Chris
>
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Thursday, August 07, 2003 3:10 PM
> To: chris.keller@active-endpoints.com; 'Ugo Corda';
> wsbpel@lists.oasis-open.org
> 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" <chris.keller@active-endpoints.com> 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.
>
>
>