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

["Chris Keller" <chris.keller@active-endpoints.com>]

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