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

["David RR Webber" <david@drrw.info>]

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_workgrou
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_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.
> >>
> >>
> >>
> >>
>
>
> -- 
> "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.
>
>