RE: [Fwd: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idand name issue]

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

Monica says to Sacha that:
"This may answer some of your questions, if you look at one of the
issues discussed in the development of v1.1 (for example, see
explanation on page 71). In addition see: Page 86, 87 (for GUID and
GUIDREF: All elements are required to have GUID (instead of xs:ID)
because of the notion of includes and packages, which would lead to
invalid XML document if xs:ID and xs:IDREF were used. This result was
part of the discuss driven by the eBA (see reference below) and the need
to globally 
uniquely identify business documents (I've included a few snippets of
the discussion below)."

+1
While qnames are sometimes used to avoid the "collision of ID values"
problem in, for example, XML scheam and  WSDL, Qnames can however
interact poorly with XMLDsig techniques especially when namespace
prefixes are remapped. So, GUID and GUIDREF is a reasonable solution
IMO.

Monica continues:
"Finally, the eBusiness Architecture, draft document, also specifies
that the business process runtime expression should be globally unique
and "include references to which Registry can provide the correct
metadata about the Business Process Runtime Expression or instance
thereof....." 
(eBA, v0.83, page 34).
Perhaps, some of the other technical folks can add more detail to
effectively answer your questions. Can you describe why you feel "having
both, the name AND ID, this invites to have logically invalid BPSS XML
instance documents"?"

I agree again with Monica here as well.

Can you provide an illustration of the pitfall we might be setting up?
It is, of course, impossible to prevent writing invalid BPSS instances,
but if there is a common trap (like ID value collision when "including")
we should consider how we can make it less probable. However, I would
point out that sometimes the "name" attribute's value (e.g, Role/@name)
is used by CPPA to pass the value to Messaging and so in some cases is
basic to the alignment that exists among BPSS, CPPA, and Messaging when
using all 3 together. A wholesale change in this area would probably not
be one that is worth taking unless there are very good reasons.