Summary: Issue with UUID's for Core Components and BIE's

[Duane Nickull <dnickull@adobe.com>]

Thank you for all the contributions.

Here is an attempt to summarize what has been said

>
> 1. Should a BIE carry the same UUID as the Core Component it was 
> derived from? 


The general consensus was "no" since they are two different artifacts. 
 I support this view and had a feeling that is what would be said.

> 2. Either in addition to, or alternatively to #1, should a BIE carry 
> its' own unique UUID?  If it is placed into a registry, the UUID will 
> be assigned to it by the registry, but it also need to be serialized 
> inline into the BIE to be used outside of the registry or in places 
> where access to the Registry RIM instance data is not possible. (real 
> world use cases exist for this). 

The general consensus was "yes".  There is also a use case that the 
schema that constrains the BIE instance (assuming they are represented 
in XML) should contain a URI to the registry, along with the UUID and 
protocol reference.

Some of this suggests that a use case exists to have a "Home Registry" 
concept for a BIE.  Lots to ponder.

> 3. If the BIE does have to have it's own UUID, possibly in addition to 
> the Core Components UUID, should this UUID be in the 128 bit algorithm 
> format OR should it use something akin to the UDEF format that can 
> convey context variables?  This may be crucial to aid business mappers 
> and integration software (rich client applications) to map the BIE to 
> existing data sources. 

The consensus was that the 128 bit UUID algorythm be used for this. 
 Reasons stated were that the 128 bit algorythm both meets the 
requirements for being unique and is an accepted principle.  UDEF is not 
currently part of ebXML.  David RRR Webber was the lone voice is 
dissention and suggested revisiting the concept of the alpha numeric 
code values.

This invites some more questions. First, should a BIE know about which 
Core Component it came from.  The CCTS specification version 2 of 11 Aug 
suggests in figure 4.2 that this is a correct assertion.  Figure 4.3 
also supports the view that a BIE can see the UMM Business Information 
Entity is came from (Not sure if "came from" is the best term to use 
here. Perhaps "Derived from"?).   I support this sine it is likely that 
there are several use cases to suuport this requirement.

Business modellers will likely want to reconcile BIE's with CC's during 
iterative business modeling.  Those responsible for integrating 
information or managing instances of information will likely require 
additional pointers to metadata (this is what makes the CCTS so 
powereful IMO).  These are just two two use cases - I know of more.  

This will logically mean that the BIE must contain both its own UUID and 
the UUID of the CC it came from.  It may optionally (highly probably in 
every instance) have to contain the other two critical attributes of the 
protocol and location to bind to in order to retreive a copy of the CC.

Let's assume that we will want a BIE to be able to reference the CC 
which it was derived from.

Should the BIE also know what context value set  (as per CCS - 8 context 
categories) were used to help constrain it?
I think the answer should be yes since this would help avoid unnatural 
proliferation of BIE's.  This would place a requirement for a 
serialization of the context value set in addition to the BIE and CC's 
themselves.  The model is fairly easy to work from and I have taken a 
crack at it.  I think that this wil fall into place fairly easily.

Aside from that, I believe personally that the CCTS is now 100% 
implementable.  The methodology has great value for all vertical and 
horizontal fields.  I do not see any major issues that would prevent it 
from being implemented within an ebXML registry.

I will incorporate this thread into the CC-Review work STC of the OASIS 
RegRep TC.

Duane

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com