RE: [ebxml-bp] Name and GUID

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Title: Message

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.

 

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.

 

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.

 

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.

 

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.