RE: [ebxml-bp] Name and GUID

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.

Dale> If I understand this example, you are saying that it is desirable to be able to refer using the name, because it allows re-association of, for example, a BusinessTransaction with a Document without needing to alter anything in the BusinessTransaction.

But, in section 7.4.2 of an earlier draft, the substitution set idea is introduced

There is a requirement for Business specifications that are less coupled to technology and business details, such as specific document formats and structures and timing parameters. Substitution sets support the capability to take a generic business process and specialize it for a specific use. For example, an ordering process may be very generic but a specific use of that process may require specific document capabilities that go beyond the generic.

A substitution set is placed in the more specific process specification and replaces or makes more explicit document definition references and attribute values. A Substitution Set is a container for one or more AttributeSubstitution and/or DocumentSubstitution elements. The entire SubstitutionSet specifies document or attribute values that should be used in place of some documents and attribute values in an existing process specification.

It seems to me then that we are providing more than one way of doing the same kind of thing. I am hoping that while we watch for enhancements, we also watch for places to simplify. So here is my question,

"Could we use substitution sets to reassociate, and restrict relational declarations to be by GUIDREF?"

Do we really lose anything? I am thinking of GUIDs and GUIDREFs as analogs of IDs and IDREFs (that is, as purely relation/association declaring syntax).

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.

Dale> +1 on above

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.

ebxml-bp message