[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
Assaf,
Still seems overly complicated to me. I've noted a simple
example that can work for a set of circumstances - if you
have a 80% use case that demands something else
beyond that - I assume you will propose something.
This is a V1.0 - it should not be too tough IMHO -
but feel free to propose what you need.
Cheers, 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 3:35 PM
Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
> I think you're confusing two things. One is an expression that gives the
> wrong result and another is expression that is invalid. If a join
> expression like 'free' + 'beer' is something that can be parsed,
> executed and will give some result (true), then fine, but the spec needs
> to be changed to allow an implementation to parse and execute such an
> expression. And currently it doesn't.
>
> And there's a good reason why it doesn't.
>
> So either way, the spec has to be changed, and I'm all for making it
> more conductive to handling DAG, which relies on keeping the current
> restrictions in place. But again, this requires looking into the usage
> of join conditions for DAG irrespective of the language, and then
> deciding on the most appropriate language to express those conditions.
>
> Arkin
>
>
> David RR Webber wrote:
>
> >Assaf,
> >
> >I think you are looking for the impossible. It is always possible
> >in computer syntax to write something that compiles just fine,
> >but does not execute at runtime to produce a deterministic result.
> >
> >The classic example is C:
> >
> >if ( x = y ) { do this; } will always succeed.
> >
> >I believe we have to say that if a programmer writes an XPath
> >expression that is meaningless in the context of the Join - then
> >clearly that is their own issue. The parser will accept it - it will
> >run it - just the programmer when they do their testing - will
> >find it does not work as they anticipated.
> >
> >All we can do in the specifications is point out the intended
> >use for the Join - and to have some examples in a conformance
> >test suite.
> >
> >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 3:14 PM
> >Subject: Re: [wsbpel] Issue 13 - Updated Proposed Resolution]
> >
> >
> >
> >
> >>Perhaps because we're not talking about the same thing. You are talking
> >>about how to execute the join condition and get a boolean value, and I
> >>don't see a problem using an XPath library there. Works for me.
> >>
> >>I am talking on validating the XPath expression when used as a join
> >>condition. I am not aware of any XPath library that can reject XPath
> >>expressions that do not conform to the restrictions imposed on join
> >>conditions. Can you direct me to an XPath library that does that? If
> >>not, how do you validate that the join condition is consistent with the
> >>restrictions imposed by the specification?
> >>
> >>arkin
> >>
> >>David RR Webber wrote:
> >>
> >>
> >>
> >>>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_workgro
u
> >>>
> >>>
> >p
> >
> >
> >>>>
> >>>>
> >>>.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_workgrou
p
> >>
> >>
> >.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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>--
> >>"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.
> >>
> >>
> >>
> >>
>
>
> --
> "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.
>
>
> 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.
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]