Re: [wsbpel] Issue - 11 - Ambiguous insertion points

["Danny van der Rijn" <dannyv@tibco.com>]

no, it can't.  there's no current way to address an insertion point for said
initialization in a currently uninitialized variable.  that's what this
discussion is about.  it's hard to grasp (at least it was hard for me) that
this "feature" doesn't exist in BPEL 1.1, but due to limitations (which
yaron has done a good job of introducing us to), receiving a message is the
only way to get data into BPEL.

IMO, this is one of the most serious defects in the current spec, and fixing
it won't be trivial.  apologies for my simplistic proposal - it wasn't meant
to be anything more than a very flimsy strawman, and i should have explained
that earlier.

danny

----- Original Message ----- 
From: "Edwin Khodabakchian" <edwink@collaxa.com>
To: <chris.keller@active-endpoints.com>; <wsbpel@lists.oasis-open.org>
Cc: "'Muruga Chinnananchi'" <muruga@collaxa.com>; "'Glenn Mi'"
<gmi@collaxa.com>; <ygoland@bea.com>
Sent: Wednesday, August 06, 2003 1:15 PM
Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points


> Chris,
>
> Invocation to an external service is not always required to initiatialize
a
> variable. Assignment from XML literal can be used as an alternative.
>
> Edwin
>
>
>
> > -----Original Message-----
> > From: Chris Keller [mailto:chris.keller@active-endpoints.com]
> > Sent: Wednesday, August 06, 2003 1:04 PM
> > To: 'Glenn Mi'; ygoland@bea.com; wsbpel@lists.oasis-open.org
> > Cc: 'Muruga Chinnananchi'
> > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> >
> > I think that the <to> specification must handle the insert
> > case.  If a bpws:selectionFailure is thrown when using a <to>
> > into a new complex part then this is a bad mistake.  How
> > would someone create a new input document to pass to an
> > invoke operation or reply to an operation if this were the
> > case?  Would they have to invoke a specialized operation just
> > to create a base document for the assignment copies to
> > proceed?  The wsbpel specification must address this case
> > whether the 1.1 specification addresses it or not.
> >
> > Chris Keller
> >
> > -----Original Message-----
> > From: Glenn Mi [mailto:gmi@collaxa.com]
> > Sent: Wednesday, August 06, 2003 2:45 PM
> > To: ygoland@bea.com; wsbpel@lists.oasis-open.org
> > Cc: Muruga Chinnananchi
> > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> >
> > Yaron:
> >
> > My understanding of the to query is close to "find and replace"
> > than "insert". Your example, according to my understanding of
> > the spec, will end up throwing a bpws:selectionFailure fault.
> > Because in page 33, the spec states that:
> >
> > "If the location path selects zero nodes or more than one
> > node, then the standard fault bpws:selectionFailure MUST be
> > thrown by a compliant implementation".
> >
> > And the spec doesn't make distincion between the query string
> > in <from> element or <to> element.
> >
> > Glenn Mi
> > 650-801-6297
> > Collaxa, Inc.
> > 1600 Bridge Parkway
> > Redwood Shores, CA 94065
> >
> >
> > -----Original Message-----
> > From: Yaron Goland [mailto:ygoland@bea.com]
> > Sent: Wednesday, August 06, 2003 10:56 AM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Issue - 11 - Ambiguous insertion points
> >
> >
> > Imagine two variables.
> >
> > Variable Name: Yippy
> > Part Name: P1
> > Value: <yippy/>
> >
> > Variable Name: Foo
> > Part Name: P1
> > Value: <foo><bar/></foo>
> >
> > The imagine executing:
> >
> > <copy>
> > <from variable="Yippy" part="P1" query="/"/>
> >       <to variable="Foo" part="P1" query="/foo/blah"/> </copy>
> >
> > Where does <blah> end up?
> >
> > The situation is ambiguous because the query string in the to
> > could legally resolve to either:
> >
> > <foo>
> >    <blah><yippy/></blah>
> >    <bar/>
> > </foo>
> >
> > or
> >
> > <foo>
> >    <bar/>
> >    <blah><yippy/></blah>
> > </foo>
> >
> > ?
> >
> > In other words the XPATH in the query string (having resolved
> > to 0 nodes and thus, according to the proposed language being
> > treated as an insert) is ambiguous.
> >
> > The problem, near as I can tell, is that XPATH is only
> > designed to point at values that do exist in the infoset
> > where what we really want to do is to point at locations that
> > don't have a value in them.
> >
> > This means that in order to support insert behavior we will
> > need to add information that is not already in XPATH. One
> > possible way around this would be to explicitly identify the
> > location where the value is to be inserted. We could, for
> > example, add the beforeinsertionPoint attribute which would
> > specify that the location identified in the query, if it
> > resolves to null, should be created as the sibling before the
> > point identified in beforeinsertionPoint. One would also
> > imagine an afterinsertionPoint attribute.
> >
> > For example,
> > <copy>
> > <from variable="Yippy" part="P1" query="/"/>
> >       <to variable="Foo" part="P1" query="/foo/blah"
> > afterinsertionPoint="/foo/bar"/>
> > </copy>
> >
> > Would result in P1 of Foo containing:
> > <foo>
> > <bar/>
> > <blah><yippy/></blah>
> > </foo>
> >
> > There are edge cases that have to be addressed. For example,
> > using the values of Foo and Yippy as defined at the start of
> > this e-mail, what happens in this case?
> > <copy>
> >       <from variable="Foo" part="P1" query="/"/>
> > <to variable="Yippy" part="P1" query="/yippy/"
> > beforeinsertionPoint="/yippy/"/>
> > </copy>
> >
> > In this case beforeinsertionPoint would resolve to 0 nodes as
> > well. I suspect that should just be an error and we would
> > need a fault to identify it.
> >
> > This whole thing feels really ugly to me so I'm guessing I've
> > made some huge mistake someplace.
> >
> > Yaron
> >
> > P.S. What we really need is a proper XPATH update language
> > but my understanding is that the W3C is only now starting to
> > work on that.
> >
> > -----Original Message-----
> > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > Sent: Wednesday, August 06, 2003 10:08 AM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Issue - 11 Query in <to> close should allow
> > assigning to new locations
> >
> >
> > I would like to open discussion on this issue (and volunteer
> > to champion it).
> >
> > The issue is that in section 14.3 dealing with assignment,
> > there is the following verbiage:
> >
> > "For XPath 1.0, the value of the query attribute MUST be an
> > absolute locationPath (with '/' meaning the root of the
> > document fragment representing the entire part). It is used
> > to identify the root of a subtree within the document
> > fragment representing the part. <b>The location path MUST
> > select exactly one node. If the location path selects zero
> > nodes or more than one node during execution, then the
> > standard fault bpws:selectionFailure MUST be thrown by a
> > compliant implementation.</b>"
> > (emphasis added)
> >
> > This means that the only way to get an initialized value into
> > a variable is to receive a message from elsewhere.  This is,
> > I believe, far too restrictive.  I propose that the wording
> > be changed to
> >
> >  "For XPath 1.0, the value of the query attribute MUST be an
> > absolute locationPath (with '/' meaning the root of the
> > document fragment representing the entire part). It is used
> > to identify the root of a subtree within the document
> > fragment representing the part. <b>When the expression is
> > used inside a <from> element, the location path MUST select
> > exactly one node. If the location path selects zero nodes or
> > more than one node during execution, then the standard fault
> > bpws:selectionFailure MUST be thrown by a compliant
> > implementation.  When the expression is used inside a <to>
> > element, and it selects 0 nodes, then the expression should
> > be treated as the location that the value will have after it
> > is inserted.</b>"
> >
> > This probably isn't the best wording, and I'd love someone to
> > clean it up a bit, but I think you get the general idea.
> >
> > Danny van der Rijn
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
> >
> >
>
>
>