MHonArc v2.5.2 -->
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
supposed to be the
role URI, not the nameCheers,Christopher
Ferris
Architect, Emerging e-business Industry Architecture
email:
chrisfer@us.ibm.com
phone: +1 508 234 3624Cliff 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