Re: [ebxml-bp] Name and GUID

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

Dale Moberg wrote:

> David,
>  
> First, I do not think that the GUIDs used in BP are the same as those 
> of the registry, nor should they be.
>  
> Second, I am uncertain whether any real permanent referential label is 
> implied in being a GUID within a BPSS instance. I did not find any 
> definitive statement in recent drafts (though I might have missed 
> one). Maybe Monica, JJ or Martin could help on this question.
>  

mm1: If you look at the original question by Kenji Nagahashi and my 
response, taking the eBA (eBusiness architecture 0.83) reference, it 
indicates that specific design and runtime artifacts derived from BPSS 
may be referenced by a Registry (information model and expressions). 

> That is, it is my understanding that the GUID/GUIDREF constructs are 
> being used to solve two technical problems The first is setting up a 
> relation (association) between or among elements, such as a relation 
> between a BusinessTransaction and a Document. The second is that the 
> solution to the first problem must survive even when new packages are 
> imported. Global uniqueness is then being used to avoid collision of 
> referential devices as they are used to declare relationships.

mm1: In the context of BPSS, this is true. The Registry requirement is 
secondary (and optional) but is also important. Please see posting from 
Nikola Stojanovic. Later in the eBA, the model *should be capable of 
being referenced* in registry query. [1]   Taking more from a later 
section, "During the design phase, the runtime expression instance shall 
be capable of referencing the business information in a way that is 
uniquely identifable, to aide in the Discovery Phase...." The business 
information, in the context of eBA, may relate to core components.  Also 
referencing back to the ebRS (v2.5), "All classes derived from 
RegistryObject have an id that is a Universally Unique ID as defined by 
[UUID].....If UUID based id is not specified, then it must be generated 
by the registry when a new RegistryObject instance is first submitted to 
the registry."  [1] Note: I've cc: Farrukh Najmi and Nikola Stojanovic 
who may wish to provide further clarity or detail.

 There is no real provision for any registry of these GUIDs to 
be systematically used as the "canonical name" for the information items 
pointed to.

mm1: I believe you are correct, Dale but will defer to Farrukh and 
Nikola to input here.

> So I could take a given BPSS instance with its GUIDs and replace all 
> the GUIDs (and update the GUIDREFs accordingly) and I would not have 
> necessarily created a substantially new BPSS with new semantic 
> significance. That is why I was indicating that I considered them 
> only syntactical constructs.
>  
> Now if we do have a requirement for canonical names for information 
> items in BPSS instances, I think that is a new requirement (to me 
> anyway) and we should consider whether we want to take it on. I also 
> think we want to know why we need a canonical naming system, what the 
> uses for these names is to be, and what conformance burdens are placed 
> on implementations for their correct usage. If we do go this 
> direction, and I am not endorsing it here, I wonder whether we would 
> then need a registry for these semantic constants and 
> some organizational body maintaining the canonical name list.
>  

mm1: I believe we need more discussion whether we "do have a requirement 
for canonical names for information items in BPSS instances".   John, 
can you be more specific to the intent you had in mind in Monday, 8 
December call? Our original goal was to provide uniqueness within a 
package.  Would imposing this type a requirement pose any barrier to 
adoption? Dale, it appears your inference here is yes.

> If you are familiar with IANA or the ISO/ITU OID systems, I think you 
> may get a glimpse of the burdens we might be assuming. I personally 
> would be reluctant to take on the burden of a canonical systematic 
> naming project within our TC.
>  
>  

>  
>
>     -----Original Message-----
>     *From:* David RR Webber [mailto:david@drrw.info]
>     *Sent:* Friday, December 12, 2003 4:11 PM
>     *To:* Dale Moberg; Jean-Jacques Dubray; ebXML BP
>     *Subject:* Re: [ebxml-bp] Name and GUID
>
>     Dale,
>      
>     Your last point brings up why in CAM we are using UID coupled with
>     domain
>     reference (alias) as the linkage point.  The reason is that the
>     registry assigns
>     a new GUID everytime something is inserted.  This can be disastrous if
>     you have referenced something widely by GUID, and you make a small
>     change to it - and that GUID is now deprecated - or you store the
>     exact
>     same thing in a different registry - it will get a new GUID -
>     (happens when
>     you move from test environment to production forinstance - or you take
>     a design from someone else and import it). 
>      
>     Whereas - using the UID system you can always find the latest
>     version,
>     regardless of its location - even across a federation of
>     registries.  So just
>     depends what you are doing.  If you exactly require a single explicit
>     reference - GUID - but if you are making a logical reference in
>     preference -
>     UID plus locator alias.
>      
>     This - and other areas - is why I'm suggesting that we give
>     implementers
>     flexibility with the ID values they store to match the production
>     environment.
>      
>     DW.
>