[ebBP] 2/23/2/004: WI 55 Late Binding [RSD] - Reference Only

["Monica J. Martin" <Monica.Martin@Sun.COM>]

Discussion|OASIS.ebBP.WI55-Late Binding;
Topic|;
Point|Summary proposal for upcoming vote for v2.0;

mm1@

EXCUSE DUPLICATE - I THINK I MAY HAVE HAD A MISTAKE IN MY SYNTAX, SO 
FORGIVE ME.

Martin, is it reasonable to assume we could make a decision on (1) below 
and take (2) item to discuss David's proposal and in the OASIS symposium 
[1]? I think we will learn quite a bit between now and the end of April. 
The ongoing discussions may be valuable input to understand (2) more 
fully and we can then build on that experience and resolution of key 
issues we currently have in work (roles, BT patterns, signals, 
references, reusability, etc).

Team, are we ready to bring this to a formal discussion and vote.

[1] Given OASIS symposium vote - remember to vote everyone on existing 
open ballot through 27 Feb.  

||mmer@
Dear all,
    I believe there are two non-mutally exclusive alternatives on
the table:

    1) A lightwight function based proposal below.         Advantages: 
works in BPSS with no addons
                handles multiple language bindings
                has default to cover simple back stop
        Disadvantages:
                Language Bindings reduce
interoperability
                Would not work with CPP/A 2.0 which
expects durations in time fields
    
    2) External Context Management Tool         This tool combines the 
need for CPP/A to be able to
change values based on Context.  It supplies Key parameter values to CAM
which are needed for its flexible approach to content and allows the
BPSS to be unchanged.
       
        Advantages: No change to BPSS required
                Helps CAM and BPSS
                Could change more than time fields
        Disadvantages:
                Not understood as an architectural piece
                Needs CPP/A to Change
                Needs development of lightweight
CAM-like Processor to manage options

    In my opinion we culd do both in the timescales we are talking
about.  Option 2 can be developed with no reference inside the BPSS
document other than stating Late Binding is not handled by the BPSS.
Option 1 would need more explanation to work for example how would
functions access BPSS fields etc.

    There you have it.  We now must choose.  For my vote I think we
should go for both.  Functions of limited nature for Time Fields only
and ebContext for other parts of the process.
||@mmer

mmer@
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.
@mmer
@mm1