OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]