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

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

DRRW@

Monica,

I've not seen any other comments here.

My sense is that while appearing to be benign and easy
- the <function/> approach here is in fact identical
to the context approach - but in reverse - in the way
it is using the external XML instance - but suffers from
restrictions - and does not handle the boundaries
anywhere near as cleanly..

Here's what I see going on - there really is no
difference from a process point of view between
a <function/> call out from BPSS XML to a Java
program that then returns a result value from a
list of choices - to the context approach where the
context Java program reads some XML then directs the BPSS
XML.   And Dale correctly brings up the issue of
fault handling from the <function/> approach, which
is not an issue for the context mechanism.

Given this - my main statement earlier this month -
that the right way to handle this is via a Technical Note
on context - and to not attempt to band-aid something
in BPSS itself - still stands.  There's more I can add
but we can discuss this on the call today.

The other key thing I see is - if you are writing Java
code to do this - its just as much effort - so why not
complete the full context mechanism and do this
right - and then what is the "short approach" saving?

IMHO - nothing.  Let's do this right and put in place
an XML driven context system - instead of relying on
half-baked <function/> call outs which will just harm
interoperablity and consistency of the BPSS model
long term.

Thanks, DW.


----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>; "Keith Swenson"
<KSwenson@us.fujitsu.com>; <kswenson.nospam@fsw.fujitsu.com>
Sent: Sunday, February 22, 2004 9:52 PM
Subject: [ebxml-bp] [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
>
>
>
>
@DRRW