OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


-- 
"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]