RE: [wsbpel] Issue 13 - Updated Proposed Resolution]

["Yaron Goland" <ygoland@bea.com>]

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.