Role CPPA, BPSS and MSG alignment. RE: [ebxml-msg] Additional feedbackto ebMS2.0 and CPPA

[Dale Moberg <dmoberg@cyclonecommerce.com>]

The version 2.0 CPPA does not document Role

as being obtained from the xlink:href attribute

on the CPPA Role element. Rather the xlink is

documented as a pointer into the

XML where the Role is defined.

 

After version 1, a number of questions remained about aligning  BPSS values with

MSG values, especially for Service, Action, Role, retry, etc. Brian, Hima, Arvola, Pallavi

and others identified residual issues. Not the place to review all this, but for "Role" here

is the outcome I recall:

 

BPSS made name and nameId _required_ attributes on Role. The name attribute was to

contain the value. While MSG said that this "should" be a URI, BPSS did not enforce

this datatype and instead chose to make the "name" attribute type xsd:string. This was

as close as the alignment of MSG and BPSS got. I think nameId, of type ID, is not

for MSG consumption. CPPA did use it in the xlink reference to the place in the BPSS

instance where a Role value is defined. The point was that because the "name" attribute

was required we CPPAers could count on it having a value, so when BPSS is used,

that is where the Role value comes from. Otherwise, MSG can just pull it out of

the CPPA's AII in Role/@name (as approximately found in Appendix F). I think we

need to be more explicit in both Appendix F table and the text though so Cliff

does not have to support both values. I think IIC should probably put this

in an implementation guide-- that the wary implementer will accept both values.

Using the xlink:href is, however and as far as a quick review revealed,

_not_ explicitly specified as holding the desired value for MSG header. The problem I see is

that we have been explicit enough that the value should come from the name attribute.

 

These are my recollections this morning.

I did not dig back in messages or notes.

I do remember Chris maintaining, as he

does about many potential values,

that they should be URIs which

is a "CF certified good thing(tm)"

However, I think Chris's thought only made

it as far as supporting

a "should be URI" in the messaging spec.

 

Dale Moberg

 

 

-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com]
Sent: Tuesday, October 29, 2002 2:52 PM
To: Cliff Collins
Cc: Doug Bunting; ebXML Messaging; iwasa
Subject: RE: [ebxml-msg] Additional feedback to ebMS2.0 and CPPA

supposed to be the 
role URI, not the name 

Cheers, 

Christopher 
Ferris
Architect, Emerging e-business Industry Architecture
email: 
chrisfer@us.ibm.com
phone: +1 508 234 3624 

Cliff Collins <collinsc@sybase.com> wrote on 10/29/2002 
04:44:36 PM:

> >
> > > 3. It is ambiguous which value 
you should use
> > >     for Role element under From and 
To element
> > >     in the MessageHeader.
> > 
>     
CollaborationProtocolAgreement/PartyInfo/CollaborationRole/Role@name
> 
> >                     
or
> > >
> > 
CollaborationProtocolAgreement/PartyInfo/CollaborationRole/Role@xlink:href
> 
> >     There is description that URI is recommended for the 
value
> > >     but sample of the CPPA specification is 
using the other one:
> > >     @name : "Buyer"
> 
> >     @xlink:href : 
"http://www.rosettanet.org/processes/3A4.xml#Buyer"
> >
> > 
I'm not entirely certain what the issue is here.  Are you commenting 
on
> > another ambiguous interaction between the CPP/A or BPSS 
documents
> > and an ebXML
> > Message conforming to those 
requirements, something similar to our earlier
> > discussions around 
the Service and Action values?  If I remember
> > 
correctly,
> > those earlier discussions were resolved (after 
discussion between
> > the TC's and
> > with UN/CEFACT) in the 
CPP/A or BPSS specifications.  Our current
> > specification 
certainly does not describe the specific source in a BPSS or
> > CPP/A 
instance for the Service or Action values.  Are you suggesting a
> 
> different approach for the Role element value or am I missing the
> 
> real issue?
> >
> 
> I think what Iwasa is talking 
about here is the same confusion that happened
> in the Drummond interopt. 
When sending/receiving a message, the MSH tries to
> get the role for the 
partyId for the given To/From element. The problem is
> what is the value 
of the "role" in the MSH to/from element from the CPA.
> Assuming below is 
the XML for the role in the CPA:
> 
> <tp:Role tp:name="buyer" 
xlink:type="simple"
> 
xlink:href="http://ebxml.org/processes/buySell.xml#buyer"/>
> 
> 
Some implementers took the "name" as the role to insert/verify on a 
ebxml
> message while some took the href.
> 
> Personally, I 
thought it was the href since the MSH spec says this is
> "preferred to be 
a URI". However, we had to implement comparing against
> both. It would be 
nice if the spec was clear which value from the CPA should
> be 
used.
> 
> Cliff
> 
> 
> 
----------------------------------------------------------------
> To 
subscribe or unsubscribe from this elist use the subscription
> manager: 
<http://lists.oasis-open.org/ob/adm.pl>