[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
sounds good. i'm out the rest of the week, but i'll try to get mine in
soon.
danny
----- Original Message -----
From: "Chris Keller" <chris.keller@active-endpoints.com>
To: "'Danny van der Rijn'" <dannyv@tibco.com>; <>
Sent: Wednesday, August 13, 2003 4:09 PM
Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> Danny,
>
> Yes that is your proposal. Should we each reformulate our proposals and
> submit them to the list. All the running commentary and evolving
> thoughts make it difficult to follow the thread.
>
> BTW - I am not against the new assign operations types (beyond copy)
> being introduced. My thinking was the expression (with new bpws:
> functions) based approach would allow us to use copy to/from for most of
> the use cases and would introduce very little changes in the current
> specification. I think the outcome is the same either way. We
> introduce a more functional mapping capability to assign.
>
> Chris
>
> -----Original Message-----
> From: Danny van der Rijn [mailto:dannyv@tibco.com]
> Sent: Wednesday, August 13, 2003 5:45 PM
> To: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
>
> edwin -
>
> this is pretty much my proposal. read down about 25 included messages
> ;-)
>
> danny
> ----- Original Message -----
> From: "Edwin Khodabakchian" <edwink@collaxa.com>
> To: <chris.keller@active-endpoints.com>; "'Danny van der Rijn'"
> <dannyv@tibco.com>; <wsbpel@lists.oasis-open.org>
> Sent: Wednesday, August 13, 2003 2:39 PM
> Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
>
>
> > Chris,
> >
> > Do you think that it would be possible to transpose
> >
> > <assign>
> > <copy>
> > <from expression="'blah'"/>
> > <to expression="bpws:insertVariableNode('variable',
> > 'part',
> > 'bar,
> > '/foo',
> > blah')
> > />
> > </copy>
> > </assign>
> >
> > To a more data driven approach
> >
> > <assign>
> > <insert position="..">
> > <from...>
> > <to...>
> > </insert>
> > </assign>
> > ?
> >
> > Thoughts?
> >
> >
> > > -----Original Message-----
> > > From: Chris Keller [mailto:chris.keller@active-endpoints.com]
> > > Sent: Wednesday, August 13, 2003 2:18 PM
> > > To: 'Danny van der Rijn'; wsbpel@lists.oasis-open.org
> > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > >
> > > Danny,
> > >
> > > I agree that we need to develop one of these into a
> > > reasonable proposal.
> > > Perhaps if some of the other active discussers of this issue
> > > could chime in then we can decide on how to move forward.
> > >
> > > In response to your last set of questions/clarifications:
> > >
> > > <DV> no, it's due to the fact that the function inserts a
> > > node (empty i assume. validation?) whose sole purpose is to
> > > be <copy>d over. so the node needs to be created, and then
> > > immediately it's garbage. </DV>
> > >
> > > Perhaps, but in my thinking it is the empty content being
> > > replaced not the node itself. And I assume validation is at
> > > the end of the activity and during the execution of any
> > > activity the content is more volatile.
> > >
> > > <DV> i think i understand. is it right that if you want to
> > > cause this to do "my" append, you leave off the child
> > > expression? if so, how do you choose which child of the
> > > parent the new expression will become? </DV>
> > >
> > > You are right. The child is specified by the childQName (the
> > > third parameter). Also we have some mistakes in the document
> > > fragments resulting from the examples (the blah text was not shown):
> > >
> > > <copy>
> > > <from expression="'blah'"/>
> > > <to expression="bpws:insertVariableNode('variable', 'part',
> > > 'bar, '/foo', blah')/> </copy>
> > >
> > > It would create the following fragment:
> > >
> > > <foo>
> > > <bar>blah</bar>
> > > <blah/>
> > > </foo>
> > >
> > > The same goes for the other fragments.
> > >
> > > Chris
> > >
> > > -----Original Message-----
> > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > Sent: Wednesday, August 13, 2003 4:33 PM
> > > To: wsbpel@lists.oasis-open.org
> > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> > >
> > > i'm starting to understand your syntax some more. my
> > > question is where do we go from here? we're going to have to
> > > develop one of these into a reasonable proposal. i'd prefer
> > > not to do both.
> > >
> > > additional comments inline with <DV>.
> > >
> > > ----- Original Message -----
> > > From: "Chris Keller" <chris.keller@active-endpoints.com>
> > > To: "'Danny van der Rijn'" <dannyv@tibco.com>;
> > > <wsbpel@lists.oasis-open.org>
> > > Sent: Wednesday, August 13, 2003 12:27 PM
> > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > >
> > >
> > > > Danny -
> > > >
> > > > See clarifications below (marked with CK>>>)
> > > >
> > > > Also got your note on remove and rename, agreed still an open
> issue
> > > > using my syntax.
> > > >
> > > > Chris
> > > >
> > > > -----Original Message-----
> > > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > Sent: Wednesday, August 13, 2003 3:10 PM
> > > > To: wsbpel@lists.oasis-open.org
> > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > >
> > > > ahh. i got confused by the 'bar' in the to expression from
> before.
> > > >
> > > > > <copy>
> > > > > <from .../>
> > > > > <to expression="bpws:insertVariableNode('variable', 'part',
> > > > > 'bar','/foo',
> > > 'blah')/>
> > > > > </copy>
> > > >
> > > > in your latest clarification it goes to the <from> element
> > > if i'm not
> > > > mistaken.
> > > >
> > > > so now we're down to the nitty gritty details. thank goodness ;-)
> > > i'm
> > > > perfectly happy with the overall format of your suggestion.
> > > however,
> > > i
> > > > have
> > > > some objections to parts of it.
> > > >
> > > > objection #1: i don't like the idea of a function creating
> > > a node that
> > > > is
> > > > about to be changed by the <copy> element. that's extra overhead.
> > > >
> > > > CK>>> Unsure if there is much overhead, this could be caused by
> > > > CK>>> the confusion that the child path(s) is relative to the
> > > > CK>>> parent path which I point out more below.
> > > >
> > >
> > > <DV> no, it's due to the fact that the function inserts a
> > > node (empty i
> > > assume. validation?) whose sole purpose is to be <copy>d
> > > over. so the
> > > node
> > > needs to be created, and then immediately it's garbage. </DV>
> > >
> > > > objection #2: you still don't differentiate between inserting
> before
> > > and
> > > > after. when operating on yaron's now canonical
> > > >
> > > > <foo>
> > > > <blah/>
> > > > </foo>
> > > >
> > > > and the function is
> > > > <copy>
> > > > <from expression="'blah'"/>
> > > > <to expression="bpws:insertVariableNode('variable', 'part',
> > > '/foo/bar,
> > > > '/foo', /foo/blah')/>
> > > > </copy>
> > > >
> > > > do you get
> > > > <foo>
> > > > <bar>
> > > > <blah>
> > > > </foo>
> > > > (insert before)
> > > >
> > > > or
> > > >
> > > > <foo>
> > > > <blah>
> > > > <bar>
> > > > </foo>
> > > > (insert after)
> > > >
> > > > just to be clear, my proposed append operation would yield
> > > > <foo>
> > > > <blah>
> > > > <bar/>
> > > > </blah>
> > > > </foo>
> > > > with the optional parameter determining between which siblings bar
> > > would
> > > > get
> > > > placed. in this case, there were no siblings, so the parameter
> was
> > > > moot.
> > > >
> > > > CK>>> I believe the confusion is caused by the fact that my
> > > childPath
> > > > CK>>> is relative to the parent path so it should read:
> > > > CK>>> <copy>
> > > > CK>>> <from expression="'blah'"/>
> > > > CK>>> <to expression="bpws:insertVariableNode('variable', 'part',
> > > > 'bar',
> > > > CK>>> '/foo', blah')/>
> > > > CK>> </copy>
> > > > CK>>>
> > > > CK>>> which would produce:
> > > > CK>>> <foo>
> > > > CK>>> <bar>
> > > > CK>>> <blah>
> > > > CK>>> </foo>
> > > > CK>>>
> > > > CK>>> and the flip side would be
> > > > CK>>> <copy>
> > > > CK>>> <from expression="'blah'"/>
> > > > CK>>> <to expression="bpws:appendVariableNode('variable', 'part',
> > > > 'bar',
> > > > CK>>> '/foo', blah')/>
> > > > CK>> </copy>
> > > > CK>>>
> > > > CK>>> which would produce:
> > > > CK>>> <foo>
> > > > CK>>> <blah>
> > > > CK>>> <bar>
> > > > CK>>> </foo>
> > > > CK>>>
> > > >
> > >
> > > <DV> i think i understand. is it right that if you want to cause
> this
> > > to do
> > > "my" append, you leave off the child expression? if so, how do you
> > > choose
> > > which child of the parent the new expression will become? </DV>
> > >
> > > > objection #3: i'm not thrilled with the overloading (optional
> > > parameter
> > > > changes function from append to insert).
> > > >
> > > > CK>>> ok, but there is precedent in the specification with the
> > > > CK>>> bpws:getVariableData function.
> > > >
> > >
> > > <DV> it's not overloading in general that i'm opposed to. i think
> that
> > > the
> > > current overloading is a bit more clear. </DV>
> > >
> > > >
> > > > objection #4: might not be an objection, but it looks to me
> > > like some
> > > of
> > > > the
> > > > parameters are redundant.
> > > >
> > > > CK>>> I think this is caused by the misunderstanding on the
> relative
> > > > nature
> > > > CK>>> of the child paths and nodes.
> > > >
> > >
> > > <DV> got it. </DV>
> > >
> > > > feeling like a lot of progress is being made (even if it's
> > > just the 2
> > > of
> > > > us
> > > > reading...)
> > > >
> > > > CK>>> Agreed
> > > >
> > > > danny
> > > >
> > > > ----- Original Message -----
> > > > From: "Chris Keller" <chris.keller@active-endpoints.com>
> > > > To: "'Danny van der Rijn'" <dannyv@tibco.com>;
> > > > <wsbpel@lists.oasis-open.org>
> > > > Sent: Wednesday, August 13, 2003 11:39 AM
> > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > >
> > > >
> > > > > Understood, the xupdate usage was functionality not
> > > syntax. Thanks
> > > > for
> > > > > clarifying. In that case I think we are in heated agreement.
> We
> > > only
> > > > > deviate in the style in which it should be implemented. In the
> > > style
> > > > of
> > > > > copy I suggested the <from> contains the data to be copied to
> the
> > > > newly
> > > > > created node which the function created and placed (as dictated
> by
> > > the
> > > > > parameters) in the XML fragment. Here is a proposed
> > > syntax for your
> > > > use
> > > > > cases.
> > > > >
> > > > > Case 1:
> > > > > <insertBefore>
> > > > > <from/>
> > > > > <to select="XPath Expression evaluates to one node"/>
> > > > > </insertBefore>
> > > > > creates a sibling before the select expression
> > > > >
> > > > > becomes:
> > > > > <copy>
> > > > > <from/>
> > > > > <to expression="bpws:insertVariableNode('variable',
> > > 'part', 'qname
> > > > of
> > > > > new element, 'parentPath part of your xpath expression
> > > evaluates to
> > > > one
> > > > > node', 'path of sibling to insert before evaluate to one
> node')/>
> > > > > </copy>
> > > > >
> > > > > The reason for splitting the parent and sibling paths in
> > > my function
> > > > is
> > > > > that the sibling path is optional, which is a reasonable use
> case.
> > > > >
> > > > > Case 2
> > > > > <insertAfter>
> > > > > <from/>
> > > > > <to select="XPath Expression evaluates to one node"/>
> > > > > </insertAfter>
> > > > > creates a sibling after the select expression
> > > > >
> > > > > Becomes:
> > > > > <copy>
> > > > > <from/>
> > > > > <to expression="bpws:appendVariableNode('variable',
> > > 'part', 'qname
> > > > of
> > > > > new element, 'parentPath part of your xpath expression
> > > evaluates to
> > > > one
> > > > > node', 'path of sibling to append after evaluates to one
> node')/>
> > > > > </copy>
> > > > >
> > > > > Case 3:
> > > > > <append>
> > > > > <from/>
> > > > > <to select="XPath Expression evaluates to one node"
> > > child="integer
> > > > > XPath
> > > > > expression"? />
> > > > > <append>
> > > > > creates a child of select expression at the child-th position.
> > > child
> > > > > defaults to last().
> > > > >
> > > > > Becomes:
> > > > > <copy>
> > > > > <from/>
> > > > > <to expression="bpws:appendVariableNode('variable',
> > > 'part', 'qname
> > > > of
> > > > > new element, 'parentPath xpath expression evaluates to
> > > one node')/>
> > > > > </copy>
> > > > > Just remove optional sibling path and it defaults to last().
> > > > >
> > > > > Case 4:
> > > > > <remove select="XPath expression evaluates to one node">
> > > > > removes a node
> > > > >
> > > > > Becomes:
> > > > > Sorry didn't introduce a remove, but I agree this could have
> some
> > > > value.
> > > > >
> > > > > Case 5:
> > > > > <rename select="XPath expression evaluates to one node"
> > > > > newName="ncname"/>
> > > > > for completeness, don't have strong feelings about its inclusion
> > > > >
> > > > > Becomes:
> > > > > Sorry didn't introduce a rename.
> > > > >
> > > > >
> > > > >
> > > > > I hope this helps clarify the proposal.
> > > > >
> > > > > Chris
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > > Sent: Wednesday, August 13, 2003 2:10 PM
> > > > > To: wsbpel@lists.oasis-open.org
> > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > > >
> > > > > > The main reason for the XPath route was in response to Yaron's
> > > > comment
> > > > > > on finishing the standard on time. And this seemed like an
> > > > acceptable
> > > > > > compromise since it deviates very little from the current
> > > > > specification.
> > > > > > Introducing the xupdate syntax seemed like a bigger nut to
> crack
> > > and
> > > > > it
> > > > > > also introduces a dependency on another specification, which
> > > people
> > > > > > would need to digest.
> > > > >
> > > > > i'm not suggesting a dependency on XUpdate, just the concepts
> from
> > > it,
> > > > > which
> > > > > we're already bandying around. i'm simply using XUpdate as
> > > shorthand
> > > > > for
> > > > > the functionality that we're talking about, in whatever
> syntactic
> > > form
> > > > > it
> > > > > comes in.
> > > > >
> > > > > > <copy>
> > > > > > <from .../>
> > > > > > <to expression="bpws:insertVariableNode('variable',
> 'part',
> > > > > > 'bar','/foo',
> > > 'blah')/>
> > > > > > </copy>
> > > > >
> > > > > so what's the point of the <from> clause here?
> > > > >
> > > > > i'm not sure why changing BPEL syntax is different from
> > > adding XPath
> > > > > functions, but i realize that i haven't been too explicit
> either.
> > > > what
> > > > > i'm
> > > > > looking at is the following possible elements under <assign>:
> > > > >
> > > > > <copy>
> > > > > <from/>
> > > > > <to/>
> > > > > </copy>
> > > > > as current.
> > > > >
> > > > > <insertBefore>
> > > > > <from/>
> > > > > <to select="XPath Expression evaluates to one node"/>
> > > > > </insertBefore>
> > > > > creates a sibling before the select expression
> > > > >
> > > > > <insertAfter>
> > > > > <from/>
> > > > > <to select="XPath Expression evaluates to one node"/>
> > > > > </insertAfter>
> > > > > creates a sibling after the select expression
> > > > >
> > > > > <append>
> > > > > <from/>
> > > > > <to select="XPath Expression evaluates to one node"
> > > child="integer
> > > > > XPath
> > > > > expression"? />
> > > > > <append>
> > > > > creates a child of select expression at the child-th position.
> > > child
> > > > > defaults to last().
> > > > >
> > > > > <remove select="XPath expression evaluates to one node">
> > > > > removes a node
> > > > >
> > > > > <rename select="XPath expression evaluates to one node"
> > > > > newName="ncname"/>
> > > > > for completeness, don't have strong feelings about its inclusion
> > > > >
> > > > > end result: nice clean syntax; nothing too major added;
> hopefully
> > > > > doesn't
> > > > > require a lot more work, spec can go forward.
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Chris Keller" <chris.keller@active-endpoints.com>
> > > > > To: "'Danny van der Rijn'" <dannyv@tibco.com>;
> > > > > <wsbpel@lists.oasis-open.org>
> > > > > Sent: Wednesday, August 13, 2003 10:37 AM
> > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > > >
> > > > >
> > > > > > Danny -
> > > > > >
> > > > > > Sorry, I should have been more explicit with the example.
> Let's
> > > > take
> > > > > > the case Yaron had brought up of /foo/blah and we would like
> to
> > > > insert
> > > > > > bar as a child of foo before blah.
> > > > > >
> > > > > > So before the copy the document fragment looks like:
> > > > > > <foo>
> > > > > > <blah/>
> > > > > > </foo>
> > > > > >
> > > > > > We execute the following copy:
> > > > > >
> > > > > > <copy>
> > > > > > <from .../>
> > > > > > <to expression="bpws:insertVariableNode('variable',
> 'part',
> > > > > > 'bar','/foo',
> > > 'blah')/>
> > > > > > </copy>
> > > > > >
> > > > > > The result would be:
> > > > > >
> > > > > > <foo>
> > > > > > <bar>...</bar>
> > > > > > <blah/>
> > > > > > </foo>
> > > > > >
> > > > > > If instead we had executed the following copy:
> > > > > >
> > > > > > <copy>
> > > > > > <from .../>
> > > > > > <to expression="bpws:appendVariableNode('variable',
> 'part',
> > > > > > 'bar','/foo',
> > > 'blah')/>
> > > > > > </copy>
> > > > > >
> > > > > > The result would be:
> > > > > >
> > > > > > <foo>
> > > > > > <blah/>
> > > > > > <bar>...</bar>
> > > > > > </foo>
> > > > > >
> > > > > > The "append" versus "insert" would be used to decide whether
> you
> > > are
> > > > > > appending the new child or inserting the new child. If the
> > > sibling
> > > > > name
> > > > > > is not specified then this results in putting the new
> > > child at the
> > > > end
> > > > > > of the list or beginning of the list of children respectively.
> > > > > >
> > > > > > I don't know if we need more than these two for
> > > positioning, but I
> > > > > could
> > > > > > be wrong. If we want rename and remove functionality
> (although
> > > > rename
> > > > > > is less of an issue it is hard to make a case for when that is
> > > > needed)
> > > > > > we could do that by adding the functions that you
> > > mentioned. Also
> > > I
> > > > > > think we can leave the <copy><to...> as an update and let the
> > > > > functions
> > > > > > handle the node creation and return of the new single node
> list.
> > > > > >
> > > > > > The main reason for the XPath route was in response to Yaron's
> > > > comment
> > > > > > on finishing the standard on time. And this seemed like an
> > > > acceptable
> > > > > > compromise since it deviates very little from the current
> > > > > specification.
> > > > > > Introducing the xupdate syntax seemed like a bigger nut to
> crack
> > > and
> > > > > it
> > > > > > also introduces a dependency on another specification, which
> > > people
> > > > > > would need to digest.
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > > > Sent: Wednesday, August 13, 2003 1:07 PM
> > > > > > To: wsbpel@lists.oasis-open.org
> > > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > > > >
> > > > > > chris -
> > > > > >
> > > > > > i'm not sure i see how the new functions would be used.
> > > could you
> > > > > give
> > > > > > an
> > > > > > example? also, the insertVariableNode is ambiguous, as
> > > yaron has
> > > > > > pointed
> > > > > > out - you'd need an insertVariableNodeBefore, and an
> > > > > > insertVariableNodeAfter.
> > > > > >
> > > > > > after you do that, you could include a removeVariableNode and
> a
> > > > > > renameVariableNode. if you do that, you've got all the
> > > > functionality
> > > > > of
> > > > > > my
> > > > > > previous suggestion.
> > > > > >
> > > > > > i don't have particularly strong feelings about the
> > > syntax for the
> > > > > > provided
> > > > > > functionality, although i have a mild bias against XPath
> > > functions.
> > > > > >
> > > > > > one thing i would like to do, however, is reconcile whatever
> > > syntax
> > > > we
> > > > > > come
> > > > > > up with with the <copy><to> syntax, as it's really just an
> > > > > > updateVariableNode XPath function, and i think that it would
> be
> > > ugly
> > > > > to
> > > > > > have
> > > > > > different syntax for update than the others.
> > > > > >
> > > > > > danny
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Chris Keller" <chris.keller@active-endpoints.com>
> > > > > > To: <wsbpel@lists.oasis-open.org>
> > > > > > Cc: "'Danny van der Rijn'" <dannyv@tibco.com>;
> > > <ygoland@bea.com>;
> > > > > > <Gnosis_@compuserve.com>
> > > > > > Sent: Wednesday, August 13, 2003 6:34 AM
> > > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion points
> > > > > >
> > > > > >
> > > > > > > Here is another idea for solving this issue.
> > > > > > >
> > > > > > > Allow the <to> element to contain an expression with the
> > > following
> > > > > > > restrictions.
> > > > > > > - It must evaluate to exactly one node like the query
> > > > > > > restriction.
> > > > > > > - It must not be in an abstract process (same rationale as
> > > > > > > query).
> > > > > > >
> > > > > > > Then we introduce new XPath functions which are mandatory
> for
> > > BPEL
> > > > > > > implementations.
> > > > > > > bpws:appendVariableNode('variable', 'part', 'childQname',
> > > > > > > 'parentPath'[, 'siblingQname'])
> > > > > > > bpws:insertVariableNode('variable', 'part', 'childQname',
> > > > > > > 'parentPath'[, 'siblingQname'])
> > > > > > >
> > > > > > > These methods could be used to create specific children at
> the
> > > > right
> > > > > > > levels. We may need to have a few more functions. But
> anyone
> > > > > > > implementing a BPEL engine must already make new functions
> > > > available
> > > > > > to
> > > > > > > the XPath processor. And this seems like the least
> deviation
> > > from
> > > > > the
> > > > > > > current specification and allows some great flexibility.
> > > Although
> > > > > we
> > > > > > > may need a few more functions (TBD).
> > > > > > >
> > > > > > > The user could theoretically use the current copy <to
> > > > > variable='...'>
> > > > > > > for example:
> > > > > > > <to variable='varname' part='partname' query='querypath'/>
> > > > > > >
> > > > > > > Or an equivalent:
> > > > > > > <to expression="bpws:getVariableData('varname', 'part',
> > > > > > 'querypath')"/>
> > > > > > >
> > > > > > > This particular case is a little redundant, but we have that
> > > > > somewhat
> > > > > > > already with literal and expression, since an
> > > expression can be
> > > > just
> > > > > a
> > > > > > > quoted string.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > >
> > > > > > > - Chris
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Danny van der Rijn [mailto:dannyv@tibco.com]
> > > > > > > Sent: Tuesday, August 12, 2003 2:05 PM
> > > > > > > To: wsbpel@lists.oasis-open.org
> > > > > > > Subject: Re: [wsbpel] Issue - 11 - Ambiguous insertion
> points
> > > > > > >
> > > > > > > david-
> > > > > > >
> > > > > > > without allowing XSLT multiple inputs, you have the choice
> of
> > > > either
> > > > > > > creating some new data, or rebuilding some variable based
> only
> > > on
> > > > > > > itself. i
> > > > > > > submit that if we don't want to deal with multiple inputs
> for
> > > XSLT
> > > > > > (and
> > > > > > > i
> > > > > > > don't say that we do), then we absolutely need something
> like
> > > > > XUpdate,
> > > > > > > since
> > > > > > > the current spec doesn't have enough data manipulation
> > > > capabilities.
> > > > > > >
> > > > > > > even if we do want to deal with XSLT with multiple inputs, i
> > > still
> > > > > > think
> > > > > > > we
> > > > > > > need an XUpdate analog, since simple updates are far too
> > > > heavyweight
> > > > > > in
> > > > > > > XSLT.
> > > > > > >
> > > > > > > i'm interested to know if satish thinks the ocean is getting
> > > warm
> > > > > ;-)
> > > > > > >
> > > > > > > ----- Original Message -----
> > > > > > > From: "David RR Webber - XML ebusiness"
> > > <Gnosis_@compuserve.com>
> > > > > > > To: <ygoland@bea.com>
> > > > > > > Cc: <wsbpel@lists.oasis-open.org>
> > > > > > > Sent: Monday, August 11, 2003 6:55 PM
> > > > > > > Subject: RE: [wsbpel] Issue - 11 - Ambiguous insertion
> points
> > > > > > >
> > > > > > >
> > > > > > > Yaron,
> > > > > > >
> > > > > > > I'm glad you are filing this issue.
> > > > > > >
> > > > > > > Once you cross-over into the territory of multiple inputs,
> > > > > > > and merging, sorting, filtering - you get beyond XSLT and
> > > > > > > into the land of traditional data mappers.
> > > > > > >
> > > > > > > Why are you thinking the W3C will care about this?!?
> > > > > > >
> > > > > > > My 0.2cents on this - take a linear approach -
> > > > > > >
> > > > > > > 1) Simple transactions - a la current spec'.
> > > > > > >
> > > > > > > 2) More complex needs - but still relatively light - XSLT
> > > > > > >
> > > > > > > 3) Heavy lifting - provide a call-out mechanism and let
> > > > > > > people choose their own toolset.
> > > > > > >
> > > > > > > Implementers needing this will agree amongst themselves
> > > > > > > on what to use - we certainly do not need to start
> > > re-inventing
> > > > > > > wheels here within BPEL - we've enough other work to
> > > > > > > look at.
> > > > > > >
> > > > > > > Pass the baton - and move on.
> > > > > > >
> > > > > > > DW.
> > > > > > > ==================================================
> > > > > > > Message text written by INTERNET:ygoland@bea.com
> > > > > > > >
> > > > > > > Actually Chris nailed the missing feature for the
> > > XSLT proposal,
> > > > the
> > > > > > > ability
> > > > > > > to submit multiple inputs. Once one can specify multiple
> input
> > > > > > documents
> > > > > > > into the transform then there is no limit to what the
> > > output can
> > > > > look
> > > > > > > like.
> > > > > > > For example XSLT(foo, bar) = bar. In other words, bar
> > > is both an
> > > > > input
> > > > > > > and
> > > > > > > an output of the transform.
> > > > > > >
> > > > > > > In any case I think there are two separate issues here. One
> > > issue
> > > > is
> > > > > -
> > > > > > > we
> > > > > > > need support for transforms. This is true regardless
> > > of any work
> > > > we
> > > > > do
> > > > > > > with
> > > > > > > XUPDATE. I will file the issue with Peter.
> > > > > > >
> > > > > > > The second issue is - what is the best programming model to
> > > solve
> > > > > the
> > > > > > > insert
> > > > > > > problem? Clearly something like XUPDATE is going to be a lot
> > > > easier
> > > > > to
> > > > > > > deal
> > > > > > > with than XSLT. But I'm concerned that there is no way we
> can
> > > > finish
> > > > > a
> > > > > > > fully
> > > > > > > spec'd XUPDATE standard in time and it isn't even clear that
> > > this
> > > > is
> > > > > > > something the BPEL TC should work on. XUPDATE sounds
> > > like a job
> > > > for
> > > > > > the
> > > > > > > W3C.
> > > > > > > <
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > > > 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
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > 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]