1/7/2004: BPSS Elements and Reusability

["Monica J. Martin" <Monica.Martin@Sun.COM>]

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.