[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
> >
> >
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]