[ebBP] 2/23/2004: WI 55 Late Binding [RSD]

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

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

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

@mm1

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