OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

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


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>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC