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]


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.



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