[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] [ebBP] 2/23/2004: [RSD] WI55-Late Binding - v2.0 Options
Discussion|OASIS.ebBP.WI55-Late Binding; Topic|; Point|Differentiating capabilities for v2.0 and 3.0; 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]