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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: [ebBP] 2/22/2004: WI 55 - Late Binding [RSD] 2.0 Proposal


  Discussion|OASIS.ebBP.WI55-Late Binding;
Topic|;
Point|v2.0 expression proposal;

mm1@

||for Martin Roberts mmer@

Martin,
I like the simplistic approach you are proposing, as XPath may not be 
enough and XQuery may be too complicated. Keith, can you sign up to this 
approach? Lars and Anders, will this meet the current requirements you 
both have?

Proposed:
Allowing an extension area for functions that evaluate to the type of 
the field you are working on.  We could then allow the following:
  timeToPerform="FUNCTION(funcationName) P5D" the P5D is the value that 
the any processor that does not support functions would use or if the 
functin return an    
    exception or normal timeToPerform="P5D"
 
As an extra area in the BPSS we would then allow:
 
<Functions>
    <function language="java" name="jOrderTime" nameID="Func1">
            java static function contents
   </function>
    <function language="XQuery" name="xOrderTime" nameID="Func2">
            XQuery Function
   </function>
</functions>
 
The key to this is that any implementation would be optional for any 
processor and the binding as to how to reference values in documents and 
receipts would be implementation dependant and not upto BPSS 2.0 spec to 
define.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    ||mm1@
    Submitted to Keith Swenson who has had an email change from Keith
    Swenson < KSwenson@fsw.fujitsu.com > to Keith Swenson
    <KSwenson@us.fujitsu.com> or kswenson.nospam@fsw.fujitsu.com.
     
    Anders and Lars, I encourage you to comment on this near-term approach
    for an expression for timing only. We will continue to look at more
    solid solutions for the longer-term related to late binding (for v3.0).
     
    One question I have is if a complex expression(s) may be required.
    Please comment on Keith's near-term proposal.
     
    Keith Swenson wrote:

>  I have been following this, and brought up the discussion at the face
>  to face meeting.  I promosed to send a suggestion to the list.
>   
>  If I understand the situation proposed by Lars was that there were a
>  set of different "time to perform" values that might come into
    play is
>  a given process.  The current BPSS constrains a give process to a
>  single time to perform value.  But in the real business world there
>  are cases where parties might agree ahead of time on different
    time to
>  perform values for specific situations.  These situations might
    depend
>  upon specifics of the intersaction, such as values carried in the
>  business document.
>   
>  Why not simply allow an expression to be used in the place of the
>  constant value?  Clearly, the expression language would need to be
>  specified.  Within that language, there might be a function to read
>  one or more values from the business document.
>   
>  An example might be "if the value of the transaction is greater than
>  $50 then the time to perform should be 3 days, otherwise the time to
>  perform is 5 days".   Another example might be "if 'express service'
>  is specified then time to perform is 2 days, otherwise time to
    perform
>  is 7 days".  Presumably express service would cost more....
>   
>  Such an expression of conditions of service like this are not unusual
>  in the business world.  Both parties agree on the conditions.  There
>  is no run time modification of time to perform, there is a fixed
>  expression that specifies the time to perform.
>   
>  Such capabilities are common the process engines that I have
>  experience with, so this is not in any sense 'exotic'.
>   
>  Martin Roberts has pointed out that any such expression language
    would
>  need to also specify what would happen if the expression fails to
>  evaluate, e.g. there is no business document, or multiple business
>  document, or otherwise fails.  There would probaly need to be a
>  "default" in the case the expression fails.
>   
>  I would not really call this "late binding".  I am wondering if
>  categorizing this as "late binding" has taken the conversation down a
>  blind alley.
>   
>  While there is much to work out to finalize such an approach, before
>  doing this work, my question is simply "does this meet the original
>  requirement as described by Lars"?
>   
>  Keith D Swenson, kswenson.nospam@fsw.fujitsu.com
>  Fujitsu Software Corporation
>  1250 E. Arques Avenue , Sunnyvale , CA 94085
>  (408) 746-6276   mobile: (408) 859-1005
>   
    ||@mm1
    @mm1
     




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