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