Re: [ebxml-bp] [ebBP] 4/30/2004: Keeping the Momentum for v2.0 [RSD]

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

Monica,

Again I need to explain this at two levels - technically
and business process wise.

Just to remind everyone - this ebContext approach is
distinct and completely separate from CAM.

Its a simple ebContext XML instance file - that contains
nothing but context statements in it.

The CPA or BPSS points to the context statement
file (either / or both - I'm not religious on
this - but some people seem to prefer one over the other;
to me all that counts is there's a URI reference to where
the ebContext statements reside - pick one - my
preference is the CPA though - since that is the
business agreement - Dale however liked the BPSS
better - and no changes to the CPA - and I believe
Martin extended the BPSS schema to allow a URI
for this).

The ebContext statements tells your trading partner
explictly what part(s) of the BPSS schema you will
allow late-binding too -using XPath to identify that - so
no need for changes to the BPSS itself to do that
with flags and things.

This also makes it easy for people to apply latebinding
to an industry approved BPSS - since they do not
have to change the BPSS itself.

Then - the ebContext gives you a choice - either a
conditional context statement - that toggles the
parameter (such as TTP) based on some
context value - or a document reference to a field
that provides that value - or a combination
thereof - against that step in the BPSS.

If you want to think of this in terms of UML diagrams
you are replacing the XSD overlaying - with a
function box that says "Determine Context", and
has three sub-boxes - ebContext settings,
BPSS structure reference(s), and Document structure
value(s) as inputs to the "Determine Context" box.

Thanks, DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "David RR Webber" <david@drrw.info>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Sunday, May 02, 2004 3:48 PM
Subject: Re: [ebxml-bp] [ebBP] 4/30/2004: Keeping the Momentum for v2.0
[RSD]


>
> >mm1: (from notes) In addition, we will have the following either tailored
TC or special
> >
> >
> >>sessions over the next two weeks for:
> >>
> >>    * Conditionality of attributes: What attributes should be changed to
> >>      elements to allow for conditionality. What are the parameters for
> >>      conditionality (offshoot from our discussion on late binding and
TTP).
> >>
> >>
> >Webber: This is *exactly* the ugly side-effect that I strongly cautioned
we should
> >be avoiding.   This will cause havoc and chaos across the whole
structure.
> >
> >
> mm1: David this is not the context or transformation but the process
> specifying whether or not those values can be changed and when. The
> latter is clearly within the scope of ebBP.
>
> >I understand member implementers need to have a "quick-fix" for their
> >time-to-perform issue, but then having this influence the entire schema,
> >and have to support this in-perpetua - is exactly what we do not need -
> >especially with attendent interoperability issues.  This can potentially
> >hamstring BPSS in one stroke.
> >
> >
> mm1: Believe me this is not a quick fix but a recognition of the
> business level requirements placed on process definition itself. This
> does not preclude CAM or another mechanism usage.
>
> >The long term solution is a consistent context mechanism that works
> >seamlessly with elements and attributes.  We already have this
> >designed and detailed.  Obviously this requires a context aware
> >software component - and I understand that managers never
> >want anyone developing more code.  However - since the code
> >for this is already available as open source - there is no severe
> >development barrier here.
> >
> >
> mm1: David, these conditionality definitions relate to the process
> itself not the mechanism that applies them. The process definition has
> to state whether or not the element can be changed and when. How that is
> implemented is not being specified.
>
> >So in summary - context mechanism - good; re-wiring our entire
> >schema structure - not good.
> >
> >Thanks, DW
> >
> >
> >
>
>
>