Re: [ebxml-bp] Proposal for dynamic context for BPSS

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

Martin,

Excellent.

Thanks for the clarification.

DW.

p.s. I'm coopting you to the review team for the
      technical note document!

----- Original Message ----- 
From: <martin.me.roberts@bt.com>
To: <david@drrw.info>; <ebxml-bp@lists.oasis-open.org>
Cc: <monica.martin@sun.com>
Sent: Monday, February 09, 2004 11:08 AM
Subject: RE: [ebxml-bp] Proposal for dynamic context for BPSS


David,
I think we are arguing the same thing.  I feel that the 2.0 spec
does not need to directly reference the tech note you propose in order
for it to be a useful specification.

I fee that a tech note published in parallel to the main specs
of BPSS, CPP/A and CAM would greatly enhance all of their efforst
without requiring them to directly refernce them in the spec at this
stage.

This approach is definitely not a do nothing, but a reference
nothing approach as I feel that while the detail is going on in the spec
for 2.0 the hooks for the context will becme more understodd and we will
end up with a greater understanding without diverting the current spec.

There are other items that fall into this category - for example
: how do you provide extensions for the XML BPSS, etc.  The hooks may be
in the schemas in the 2,0 specs but not documented.  Does this prevent
their use?  I think not and therefore having the context piece reference
the specs and not the other way round builds a good loose coupling and
prevents us getting too bogged down in this potentially sticky area.

BTW, I support the approach of a context descriptor.

Martin Roberts 
xml designer, 
BT Exact
e-mail: martin.me.roberts@bt.com 
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki



-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: 08 February 2004 21:00
To: Roberts,MME,Martin,XSG3 R; ebxml-bp@lists.oasis-open.org
Cc: monica.martin@sun.com
Subject: Re: [ebxml-bp] Proposal for dynamic context for BPSS
Importance: High


Martin,

I disagree for EXACTLY the reasons you state!

It's just too trite and easy to say - oh lets not do this in V2.0,
we'll think about this later.   That's PRECISELY the
response I was seeing I'd get to this.

This ignores the fact that real implementations today are
being directly impacted because this is a gaping hole in
the current implementation that users desperately
need fixed now and is therefore crippling adoption
in areas such as Automotive and Electrical industry
use cases.

And beyond that - having this feature in V2.0 makes
a huge statement about the robustness and longterm
capabilities of BPSS as a technology.

Now - if this was a brand new issue that we'd never
anticipated before, and we done absolutely no work
on ever in the past - I might be inclined to take
the "do nothing" way out.

But that is simple NOT the case.  We've been working
on this for two whole years.   We've got a whole
spec' written and we've implemented code.  The BCM
team has their whole spec' too.  And the CCTS team
and UBL have worked this.

I'm therefore seeing that the proposed draft can be
quickly and effectively brought together.

As you pointed out - this is a parallel processing task
since it is a separate piece of XML from the BPSS
schema itself - so it is self-contained from that
respect, and will not impinge on the main V2.0
specification re-write.  That work will I'm sure
take 6 weeks in of itself - and 6 weeks is more
than enough time to complete the Technical Note
document covering the context mechanism.

We should also aim to produce use case examples from
the field to show exactly how this works in practice
for BPSS today as well.

I'm not prepared to agree that the "do nothing"
approach is the right one here at all - that will
IMHO be a disasterous choice.

Thanks, DW

----- Original Message ----- 
From: <martin.me.roberts@bt.com>
To: <david@drrw.info>; <ebxml-bp@lists.oasis-open.org>
Cc: <monica.martin@sun.com>
Sent: Friday, February 06, 2004 7:32 AM
Subject: RE: [ebxml-bp] Proposal for dynamic context for BPSS


> Dear all,
>   I would like to add my weight to this as I feel that if we want to 
> keep
2.0 of the BPSS to a reasonable scope, we are going to have to accept
that late binding really is outside of the BPSS.
>
>   One concern I have is that we have two problems which David RR 
> suggests
can be fixed by the one mechanism.  They are input of context details to
manage the document content that will be exchanged and the manipulation
of the BPSS/CPA based information that is controlling the exchange.
>
> I feel that both of the above are very much needed to plug the gaps we
have today.
> However, there seems to be a push back that says the BPSS/CPA 
> flexibility
should be expressedin the BPSS if that is know at the time of the BPSS
design - i.e. transaction timeToPerform is based on field x plus 24
hours. John Yunker said this was not an agreement time arrangement but
part of the business level process definition.
> With that in mind we have to build a bridge between these views.  My
feeling is that anything we do quickly that introduces flexibility in
the BPSS also will greatly complicate the resulting structures and
therefore could lead to an unclear solution rather than making life
easier.
>
> For this reason I propose that the BPSS does not attempt to address 
> this
issue as part of the BPSS 2.0 spec, but instead we need to discuss this
with a joint team of CPA and BPSS.  This would make a great topic for
New Orleans?
>
> There is another reason why I think this should be done outside the 
> BPSS
2.0.  I am very concerned that any expression language we say we want to
use will either prove very coomplex or too simple.  We would have to
choose a default language if we are to encourage the feature to be
interoperable, but we do not have the time to work through this to a
point where we could be comfortable that we have enough to do the job
but not too much that no one really understands the implications.
>
> Take care.
>
> Martin
>
> -----Original Message-----
> From: David RR Webber [mailto:david@drrw.info]
> Sent: Thu 05/02/2004 21:23
> To: BPSS ebXML
> Cc: Monica Martin
> Subject: [ebxml-bp] Proposal for dynamic context for BPSS
>
>
> Monica,
>
> As requested today, here is the text of the
> context proposal.
>
> Use Cases:
> =========
>
> Given that BPSS should:
>
> a) support late binding of specific parameters within
>     the BPSS based on business factors that
>     occur during a BPSS use
> b) support business modellers being able to
>     identify critical factors during creation of a BPSS
>     that effect linking and switching within a process
>     and be able to specify those and quantify their
>     details -
>     (e.g. deliveryCountry = Mexico, USA, Canada).
> c) support ability to configure BPSS flows to match
>     locale or other factors globally based on context
>     provided when a CPA is determined between
>     participants based on their own transaction
>     needs (e.g. produceType="mustRefridgerate")
> d) provide context to external components that
>     may be directed by BPSS - such as transaction
>     handling software (Java, EDI Mapper, XSLT, CAM,
>     EAI adaptor, et al), or web service step.
> e) have a mechanism to determine pre-conditions
>     for BPSS and outcomes - start, wait, or skip
>     that allows implementers to configure when
>     a BPSS should commence.
>
> Approach:
> =======
>
> Provide an XML instance, separate from but
> relating to the BPSS, specifically for managing
> context, and link to that from BPSS either
> directly (URL) or indirectly via reference in CPA
> (CPA can provide link to constrained BPSS
> context set verified by collaboration
> participants as they define their CPA).
>
> In constructing context rules within this XML
> instance simple XML will be used along with
> XPath expressions and a basic datatyping
> system founded on the W3C foundation
> data types.  This will be supplemented
> with a limited set of string referencing
> functions necessary to complete the
> data model of context rule parameters.
>
> The aim is to make this rapidly implementable
> with off the shelf simple XML development
> tools, and concise and complete to be specified
> with a supplemental Context Technical Note
> specification of 15 pages or less.  This
> supplemental document will follow the model
> used by the Registry team for their supplemental
> notes to their main specifications.
>
> Rationale:
> =======
>
> 1) A well featured context mechanism will set
>     BPSS V2.0 apart as the premier approach to
>     business orchestration using the latest
>     techniques for integration into the SOA
>     solution stack.
>
> 2) The cost of documenting the technical
>     note in 15 pages is comparable to
>     defining a lesser capability within the
>     existing BPSS with mostly the
>     same effort (XPath expression
>     definition and control mechanisms).
>
> 3) Setting this feature now for V2.0 will
>     set the foundation for V3.0 and beyond,
>     without requiring implementers to "two-step",
>     (supporting a lesser V2.0 capability that
>     then is extended later with attendent need
>     to support two related mechanisms).
>
> 4) Having a consistent context mechanism
>     that BPSS can use to manage not only
>     its own needs but can be referenced by
>     any other component that relates to the
>     BPSS provides a single consistent
>     system across the ebXML stack.
>
> 5) The context mechanism proposed is
>     already known and therefore the level
>     of effort and risk in designing it is
>     significantly less than involved in
>     starting with nothing.
>
> 6) Having a well featured context
>     system that is extensible ensures
>     that all the use cases a) thru e)
>     can be accommodated sufficiently
>     in V2.0 - therefore significantly
>     enhancing the value and utility of
>     the BPSS specification.
>
> Technical Detail:
> ============
>
> The draft proposed initial Context Technical Note
> document will be posted separately for
> reference, but it is anticipated that this
> will be completed as a work item for V2.0
> and agreed to as part of that process, by
> BPSS team members.  Input from all
> 6 use cases and worked examples can then
> be generated as part of the deliverable too.
>
> Thanks, DW.
>
>