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: RE: [wsbpel] Issue - 11 - Ambiguous insertion points


+1   

The ability to insert/update nodes is useful in general, and it sure looks
like this is an applicable case. Our (formerly eXcelon) Sonic XML database
"XIS" has the ability to do node level updates (using a syntax similar to
XUpdate).

If you are not using a tool like "XIS", then are we saying that we would
just be building our own DOM incrementally, and insert/replace/validate at
some (specified) points in the processing?

++Harvey


-----Original Message-----
From: Danny van der Rijn [mailto:dannyv@tibco.com] 
Sent: Thursday, August 07, 2003 5:11 PM
To: wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points

i'd like to table the validation question for now.  probably re-raise it as
a separate issue pointing back to this one later.  since most of it depends
on <to> being able to insert nodes, i'd like to go back to this issue.

i agree with yaron, that my previous proposal allowing <to> to select 0
nodees was in error.  i also agree with chris that this is an important
"feature" to have, if it's not a bug that it's not there.

there is half of a spec languishing out there that deals with these things.
it is called XUpdate
(http://www.xmldb.org/xupdate/xupdate-wd.html).  i can't see any IP notice
about it, so i am unclear as to those issues.

not taking the complete XUpdate as a language, but looking at the ideas
behind its primitives, i can see use for derivatives of the following as
alternatives for the <to> element when the target is a variable:

<xupdate:insert-before select="XPath expression">
<xupdate:insert-after    select="XPath expression">
<xupdate:append         select="XPath expression" child="integer
expression"?>
<xupdate:update          select="XPath expression">     (the same as BPEL's
current <to> element)
<xupdate:remove         select="XPath expression">     (no <from> element
would be required for this one...)
<xupdate:rename         select="XPath expression" newName="ncname">      (or
this one (which i slightly changed from XUpdate))

i think the semantics for these are pretty self-evident, but if not, go to
the XUpdate spec.  it's short.  again, i think it would be pretty
straightforward to nail down precise semantics, error cases, faults, etc.
but before i do that (with help?) i wanted to get a feeling of whether

1) people think that addressing this issue is as important as i do, and
2) whether people think that this is the right approach to take.

is there a way to quickly poll people on this without asking them to expound
in detail?  just ask for +1/-1 mail?  any other ideas?

danny
----- Original Message ----- 
From: "Chris Keller" <chris.keller@active-endpoints.com>
To: "'Glenn Mi'" <gmi@collaxa.com>; <ygoland@bea.com>;
<wsbpel@lists.oasis-open.org>
Cc: "'Muruga Chinnananchi'" <muruga@collaxa.com>
Sent: Wednesday, August 06, 2003 1:04 PM
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
>
>



---------------------------------------------------------------------
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]