Re: [ebxml-bp] Dynamic (late) binding proposal - take 2 now with diagram

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

Monica,

I just looked again at the proposal here - and its shockingly
close to the ebContext proposal already in two key aspects:

1) retrieves value from a named variable at bind time

2) retrieves TTP from a request document based on a
    reference (possibly XPath).

Well, well - the ebContext proposal supplies the solution
to both of these needs.  Either the named variable is
in the ebContext instance, and/or a context statement
that includes a reference to the document, namespace,
and XPath to obtain a value from.

Since this solves the 'and then a miracle happens' in
a concrete way - there remains only the 3) part of
the ebContext proposal - that uses the bpss:
namespace to reference any aspect of the BPSS
that needs to have context and a value applied to it.

Notice this then solves the dilemma of having to
promote any part of the schema from attribute to
element - so that substitution groups can be used
to apply late-binding.

Instead the 3) bpss:[XPath]  technique allows you
to provide context to any part of the structure.
Of course you really want to retain attributes - since
they can in the first place be tokenized and
enumerated, and given default values.

And of course going way down into the weeds -
programmatically this is a snap - since you just
update the DOM for the node in the BPSS
instance tree - and its done.

So in summary - if you are building a mechanism
to shoe-horn the context value parameter passing
into BPSS for late-binding - well then supporting
reading this from the XML instance of the
<ebContext> parameters file is the way to do
this - and if you are doing that - then you are
there already in implementing the full context
mechanism - since parsing the remaining parts
of the ebContext file is nothing - all the hard
work is being done.

Summary therefore is - heck - if we are passing
parameters into a late-binding around using
schema substitution groups - then lets just
complete the job using the ebContext - and then
you really do not need to have substitution groups -
just let the context statement point to the XPath
of the BPSS component - and update it in the
DOM in-situ.

This gets us to the point I've been asking for -
of a single consistent mechanism, that works
with the existing schema as-is, and provides
a simple or extended functionality that either
just passes a variable value in - or provides
an XPath expression that designates a
transaction field as the source of the
required variable value.

DW.

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: <anderst@toolsmiths.se>
Cc: <ebxml-bp@lists.oasis-open.org>; "Lars Abrell"
<lars.abrell@teliasonera.com>
Sent: Sunday, May 02, 2004 5:47 PM
Subject: Re: [ebxml-bp] Dynamic (late) binding proposal - take 2 now with
diagram


> Discussion|OASIS.ebBP.WI-53-55-LateBindingConditions;
> Topic|;
> Point|Conditions for Process Description;
>
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200404/msg00131.html;
>
> mm1@
>
> > Tell: Please find the following diagram outlining one way of
> > formulating dynamic or late bound TimeToPerform or similar parameters.
>
> mm1: Reference attached [1].
>
> > At the top there is a abstract superclass that does not turn up in the
> > document, the concrete subclasses does.
> >
> > The BindingTime speficies when binding occurs, i.e. which
> > collaborationEvent(s). (maybe this should also be an element?)
> > Default value is the value before binding occurs
> > TTP duration can be ORed together with Union.
> >
> > <TimeToPerform boundWhen="enclosingCollaborationInitiationEvent">
> >  <Union>
> >      <StaticTimeToPerform>2h<StaticTimeToPerform>
> >
> > <RequestMessageTTP>//MessageEnvelope//ResponceTime</RequestMessageTTP>
> >  </Union>
> > <TimeToPerform>
> >
> > This patterm may be used for other parameters that are candidates for
> > dynamic binding..
>
> mm1: Anders and Lars, we identified these potential attributes in the
> meeting on Wednesday [2]
> 1. Duration (**)
> 2. Type - Provide range of enumeration values (**).
>
>     a. Design
>     b. Configuration
>     c. Runtime
>
> 3. Default
> 4. Default type
> 5. Build conditionality into the Type for when it can be changed (**-via
> boundWhen)
>
> I would suggest if we identify when and to what extent the business
> process criteria are changed, we identify if a default is provided and
> if it could be accessed (3,4 above). There is also a slightly different
> question related to if the value is given or must be acquired. I would
> suggest we accommodate both, if the functionality is supported by the
> team. I am not certain this nuance is referenced in the model example
> you provided. Thanks.
>
> [1] Attachment with referenced diagram:
> http://www.oasis-open.org/archives/ebxml-bp/200404/msg00131.html. Actual
> attachment provided herein as well for interested parties.
> [2] Items I see in your proposal identified by (**).
> @mm1
>


----------------------------------------------------------------------------
----