← Prev in month ← Prev in thread
Next in thread → Next in month →

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

From
Dale Moberg <>
Date
2002-10-30T15:44:37+00:00
ID
Thread
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:]
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: 

phone: +1 508 234 3624 

Cliff Collins <> 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>
← Prev in month ← Prev in thread
Next in thread → Next in month →