Re: [ebxml-bp] 1/7/2004: BPSS Elements and Reusability

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

Monica,

I think this needs a complete re-evaluation.

What I'd like to see is a specific <include> statement aimed
at providing re-usable chunks of BPSS.

We of course had to address this early in CAM - providing
sub-assembly - and I must say - we're still not done
tweaking it all - but at least for V1.0 we have the basics
done and a reasonable simple approach - including ability
to treat sub-assemblies as objects.

I think the whole issue of ID's here is a red-herring frankly,
and we should drive around that thinking.

Here's what I think we might be better off brainstorming on.

1) In a simple party collaboration with a single logical thread
    (step A, then B, then C, then D) - re-use is directed via
   the CPA configuring of party profiles.

2) In a multi-party collaboration with multi-threads - each
    such thread can potentially be a sub-BPSS of a standard
    business function (example - shipment delivery).  What
    we really need is the ability to provide linkage control,
    (aka linkage area in BPEL) and common signalling
   techniques - so when you plug-in the sub-BPSS - it
   seats into place with the other parts automatically.

3) The notion of the master-BPSS into which you include
     re-usable sub-BPSS makes most sense.  An override
     approach (again in CAM we've specified how to do
     this generically for any aspect - and then limited it
     in V1.0 so people are trying to do silly things).

4)  What this means is that the sub-BPSS cannot be
      run on its own - its specifically designed to be
      included in - and only contains certain things.
      Similarly you cannot include just any BPSS into
      another one - it has to be designed to work as
      a sub-BPSS and be pluggable.  You should be
      able to follow some steps to convert a working
      standalone BPSS into a sub-BPSS.

Overall the idea is to have a simple and obvious way
to allow sub-BPSS re-use across an industry domain,
that is useful - without making it so complicated that
implementers and users alike will never be able to
use it anyway.

This begs the question - what makes a good re-usable
sub-BPSS - can we can figure a few of those use cases
out - then we can make a first cut and getting something
worth using?  Dare I say this - but the AutoTech GM/Nissan
is a nice example IMHO - where the parts suppliers are
mostly using the same sub-BPSS - while GM and Nissan
control the master-BPSS.... which points up another
aspect of this

5) Parties may only choose to share a sub-BPSS with a
     participant - and not the overall master-BPSS.

Thanks, DW.

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>; <jjdubray@hotmail.com>;
"Dale Moberg" <dmoberg@cyclonecommerce.com>; <martin.me.roberts@bt.com>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>; "Yunker, John"
<yunker@amazon.com>
Sent: Thursday, January 08, 2004 12:43 AM
Subject: [ebxml-bp] 1/7/2004: BPSS Elements and Reusability


> When we discussed Work Item 43 in Monday's teleconference call, Dale
> raised a point about reusability related to BPSS elements. This was
> prompted from our discussion of name and nameID, and the use of GUID and
> GUIDREF.
>
> The team asked if we could explain previous discussions that lead to the
> use of GUID and GUIDREF, and explain the intent for reusability.
>
> The earlier discussion stemmed from public comments received on the
> nameID [1]
> <<According to the UEB architecture v0.32, line 821-827 the parameters
> in BPS document are to be considered as default values and a TPA may
> override these. If the TPA does so the TPA values take precedence. This
> indicates a need of being able to uniqually identify all or most
> elements of BPSS documents such as BinaryCollaborations, Transitions,
> Business states etc. I dont think the current spec contains such
> statement. There are at least two ways to go.1. Add 'ID' identifiers to
> all specifications elements such as adding/moving ID to BusinessState
> and adding ID to Transition.2. Explicitly state that all Composite
> associations are *ordered* and therefore positional/index references may
> be used in references. The second solution may also solve the problem
> with ConditionalExpression and firing priorities/conflict resolution
> since the document order of Transitions may be the algorithm to use.....>>
>
> Resolution at that time was to: Check in specification for elements
> without identifiers – Name – attribute with a type of ID, example.
> Didn’t use the XML Schema ID type because when you have a package, the
> IDs may not be unique. Explain ID type must be unique within a given
> document.In addition, for packaging, this could be handled with an
> include (see BPSS 1.01, line 1722, section 8.1) that existed for the
> ProcessSpecification. Also see ProcessSpecification in 1.05 (See Section
> 8.1.15). Package specified at 8.1.19.Have a NAME with an associated NAME
> ID.XSD ID preferred.NAME within a package (PIP ID in name field for
> RosettaNet )
>
> As you can see some of the changes were in answer to this comment and
> the need to effectively handle packages.
>
> Martin, JJ, and John Yunker, if you can add to this discussion, I
> encourage you to do so. Thanks.
>
> [1] Comments from Anders Tell.
>
>
>
>