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