[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
Assaf, I'm not seeing this. We are successfully using a subset of XPath in CAM and it is working very sweetly. This is already implemented using the standard Java XPath libraries - and not only is it logical but also straightforward. So - there is some value / condition that needs to be referenced and tested. In BPEL I would say this is either some shared linkage area indicator - or is in a transaction. Either way you can use XPath to reference that - using a namespace if necessary to denote its source. DW. ----- Original Message ----- From: "Assaf Arkin" <arkin@intalio.com> To: "David RR Webber" <david@drrw.info> Cc: <ygoland@bea.com>; "'Maciej Szefler'" <mbs@fivesight.com>; "'rkhalaf'" <rkhalaf@watson.ibm.com>; <wsbpel@lists.oasis-open.org> Sent: Wednesday, January 07, 2004 2:57 PM Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution] > If you take the space of all XPath expressions and try to put it there, > most of them will be invalid. You can try this using just the set of > semantics expressed in XPath 1.0 and see how much of that stuff will not > pass as valid in a join condition. > > The question is not how to get the result of process it, the result is > an XPath boolean value, which XPath 1.0 supports. The question is how to > specify the set of restrictions so it applies to any generic expression > language, including unknown languages, and exactly what is the point of > doing that? If you can only use 5% of a language, are you better off > restricting it, or coming up with an alternative? > > Arkin > > David RR Webber wrote: > > >Yaron, > > > >I'm trying to grapple here with what the real problem is. > > > >I agree simple is vital - otherwise compliance testing > >becomes a vast project for one - and implementation > >another. > > > >What are why trying to do here with a JOIN? Why do > >we need a query language? Surely this is trivial - > > > >Join condition({XPath expression}, #targetnode), > > > >Where #targetnode is a standard XML IDREF anchor > >to some other point of the XML. > > > >When the condition is true you branch to the anchor. > > > >Am I missing something? > > > >DW. > > > >----- Original Message ----- > >From: "Yaron Goland" <ygoland@bea.com> > >To: "'Maciej Szefler'" <mbs@fivesight.com>; "'Assaf Arkin'" > ><arkin@intalio.com> > >Cc: "'rkhalaf'" <rkhalaf@watson.ibm.com>; <wsbpel@lists.oasis-open.org> > >Sent: Wednesday, January 07, 2004 2:31 PM > >Subject: RE: [wsbpel] Issue 13 - Updated Proposed Resolution] > > > > > > > > > >>The question is what will cause the least amount of effort for users? To > >>take an existing language that they are familiar with and routinely use > >> > >> > >and > > > > > >>then create a sub-set of it for use in join-conditions or to create an > >>entirely new language specifically for join conditions and now force users > >>to learn two languages with potentially unrelated and inconsistent > >> > >> > >syntaxes? > > > > > >>I personally favor the former. I also think that if we are to finish this > >>spec in a reasonable amount of time we should avoid creating new query > >>languages. > >> > >>Just my two cents, > >> > >>Yaron > >> > >> > >> > >>>-----Original Message----- > >>>From: Maciej Szefler [mailto:mbs@fivesight.com] > >>>Sent: Wednesday, January 07, 2004 9:55 AM > >>>To: ygoland@bea.com; 'Assaf Arkin' > >>>Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org > >>>Subject: RE: [wsbpel] Issue 13 - Updated Proposed Resolution] > >>> > >>> > >>>Consistency should be reserved for areas where there is some > >>>common domain. > >>>As Assaf points out join conditions have nothing to do with XML node > >>>selection, so why would we try to adopt an expression language aimed > >>>squarely at XML node selection crippling it so that it no > >>>longer does what > >>>it was intended to do? It makes no sense to me. If anything > >>>it makes things > >>>confusing. > >>> > >>>Would a structured XML representation such as "<and><link > >>>name="foo"/<link > >>>name="bar"></and>" satisfy your objection to creating multiple sets of > >>>grammars? > >>> > >>>-maciej > >>> > >>>-----Original Message----- > >>>From: Yaron Goland [mailto:ygoland@bea.com] > >>>Sent: Wednesday, January 07, 2004 10:08 AM > >>>To: 'Assaf Arkin' > >>>Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org > >>>Subject: RE: [wsbpel] Issue 13 - Updated Proposed Resolution] > >>> > >>>This has nothing to do with XML manipulation, this has to do > >>>with the need > >>>to have a consistent expression/query language used > >>>throughout BPEL. If > >>>someone is moving to a new expression/query language for all other > >>>expressions in BPEL they should not be forced to use a different > >>>expression/query language just for join conditions. That is why join > >>>condition must have the same syntax flexibility that is > >>>available to all > >>>other expressions/queries. > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Assaf Arkin [mailto:arkin@intalio.com] > >>>>Sent: Monday, January 05, 2004 7:00 PM > >>>>To: ygoland@bea.com > >>>>Cc: 'rkhalaf'; wsbpel@lists.oasis-open.org > >>>>Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution] > >>>> > >>>> > >>>>Yaron Goland wrote: > >>>> > >>>> > >>>> > >>>>>Imagine a prefix style XML manipulation language is > >>>>> > >>>>> > >>>>introduced that does > >>>> > >>>> > >>>>>things like "and(foo,bar)". No tool in its right mind is > >>>>> > >>>>> > >>>>going to say to the > >>>> > >>>> > >>>>>user 'well you can use the prefix style everywhere in BPEL > >>>>> > >>>>> > >>>>but this one > >>>> > >>>> > >>>>>single place, join conditions, where you have to use an > >>>>> > >>>>> > >>>>infix "foo and bar" > >>>> > >>>> > >>>>>style.' > >>>>> > >>>>> > >>>>> > >>>>> > >>>>You're right. > >>>> > >>>>I've read the spec over and over and over and I still don't > >>>>understand > >>>>what XML manipulation has to do with join conditions. I don't > >>>>see node > >>>>selection, there's no context node or any variable/function > >>>>you can use > >>>>to operate on nodes. No operators are allowed unless they deal with > >>>>binary values. If nodes are non-existent, then where does XML > >>>>manipulation come into play? > >>>> > >>>>So while I agree with the logic you presented, I still fail > >>>>to see how > >>>>it applies to join conditions. > >>>> > >>>>arkin > >>>> > >>>> > >>>> > >>>> > >>>To unsubscribe from this mailing list (and be removed from > >>>the roster of the > >>>OASIS TC), go to > >>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le > >>> > >>> > >>ave_workgroup. > >>php. > >> > >> > >> > >> > >> > >>To unsubscribe from this mailing list (and be removed from the roster of > >> > >> > >the OASIS TC), go to > >http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup .php. > > > > > >> > >> > > > > > >To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > > > > > > > -- > "Those who can, do; those who can't, make screenshots" > > ---------------------------------------------------------------------- > Assaf Arkin arkin@intalio.com > Intalio Inc. www.intalio.com > The Business Process Management Company (650) 577 4700 > > > This message is intended only for the use of the Addressee and > may contain information that is PRIVILEGED and CONFIDENTIAL. > If you are not the intended recipient, dissemination of this > communication is prohibited. If you have received this communication > in error, please erase all copies of the message and its attachments > and notify us immediately. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]