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

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

i've probably missed something, but:

what benefit would we get out of such an activity?  for output, we're still
restricted to the XPATH in the <to> clause selecting exactly one node.  or
being a whole part.  haven't gained anything there.

additionally, there would be the problem of inputs.  i would think that if
we are going to to the XSLT route, we'd want multiple ones.  how to specify?

for the "fine grained updated" use cases that we've been bandying about,
we'd be having to pass as (an) input the output.  the update wouldn't be
efficient, or easy.  you would need to regenerate
everything up to the point of the insert-after element (using copy-ofs
probably), then insert what you wanted, then regenerate everything after
that point (using copy-ofs again).

would this really be the simplest way around? i would think that the XUpdate
route would be much easier.  it's not like we're really inventing much -
it's all part of XSLT anyway, just being used in a different way.

danny

----- Original Message ----- 
From: "Yaron Goland" <ygoland@bea.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Friday, August 08, 2003 12:56 PM
Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points


> -1 on using a XUPDATE type paradigm
>
> This group is on an aggressive timeline and the idea of inventing our own
> update language seems really dangerous. While the functions may be simple
> it's always the details that get you.
>
> I think the simplest way around this problem is to do what Danny mentioned
> and introduce a XSLT activity that takes three arguments, an input, a XSLT
> and an output. That way we can inherit an already standardized solution to
> this problem and not have to re-invent any wheels.
>
> The syntax could look like:
>
> <transform xform="bpel:xslt">
> <from> <!-- As specified for assign -->
> <to> <!-- As specified for assign -->
> <xslt>
> (<import href=""> | <xsl:stylesheet ...> | <xsl:transform ...>)
> </xslt>
> </transform>
>
> The purpose of the xform attribute is to allow one to select other
transform
> technologies, for example, XQUERY.
>
> If we wanted to be really reductionist we could even get rid of assign all
> together and replace it with transform. After all, a copy is just a XSLT
> that copies everything over.
>
> Yaron
>
> > -----Original Message-----
> > From: Harvey Reed [mailto:hreed@sonicsoftware.com]
> > Sent: Thursday, August 07, 2003 2:36 PM
> > To: wsbpel@lists.oasis-open.org
> > 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
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>