References based on
names offer more flexibility specialy in case where a logically identical
element is physically different in different context. For instance, a Process PO
collaboration can be defined for various industry but the PO format will be the
different for each industry. In this case, the PO document format will be
defined in a separate package that will be included into the collaboration
package in each case.
I don't think it is
required to have the named reference required when a guid is specified
(like it is in the BPSS 1.1 schema) and as Serm told us.
The remaining question was is
there some use cases where both a named and GUID-based reference are needed.
John, I must admit that I am still not very clear on when we would need to use
both at the same time. I can see that when you create a new version of an
element, the name may remain the same, but what do you gain in the first place
to use a GUIDRef if you know that this particular element will evolve and you
are going to end up in this situation? why not use just a named reference in
that case? As soon as you store the two references at the same time, they must
then remain in synch and if you create a new version, at that time, you know for
sure what is the old GUID and the new one.
I can see that you could use both, just in the case
where there is a risk to loose the file in which the element referenced is lost.
It might then be easier to find a new one by name.
So I don't think we should make it EITHER a named
reference OR a GUID reference, having both should be allowed, but I don't see
any advantage of having both at the same time.
Jean-Jacques Dubray
attachmate
3617 131st Ave
Bellevue, WA 98006
tel: 425-649-6584
Cell: 508-333-7634