MHonArc v2.5.2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: Re: Role CPPA, BPSS and MSG alignment. RE: [ebxml-msg] Additionalfeedbackto ebMS2.0 and CPPA
Dale,
I haven't read through the CPP/A document for the details on this and
so must apologize for a potentially naive question. How explicit
is that specification about the Role@href attribute identifying the source
of the Role@name value? If it's relatively explicit, the conflict
resulting in the implementation complications Cliff has described shouldn't
have arisen. Our current Messaging document is already pretty clear*
that the Role element identifies the role in question and not the location
in some other document where that role is identified. Or, am I missing
something?
The existing note (minor recommendation at best) in the Messaging specification
could be rephrased as "In all cases, the Role element in an ebXML Message
SHOULD contain a URI. This implies the corresponding Role@name value
in a document conforming to the CPP/A specification (if such exists, see
section ...) SHOULD be a URI as that is the documented source for this
information in an ebXML Message."**
thanx,
doug
* We could discuss a minor issue about the "toAuthorizedRole and fromAuthorizedRole"
terminology that came up some time ago but isn't in the current issues
list. Does anyone remember why these terms are bold or even the context
in which they're meaningful? Did we resolve the previous issue or
just lose it?
** This wording doesn't reflect Chris' issue 16 that proposed alternate
wording for the note nor the current wording. I'm trying to get at
a meaning aligning with the CPP/A specification. Of course, it remains
a bit odd to have a dependent specification (the Messaging document in
this case) say "take this value from here" as well as "this value should
look like this". Why isn't the "should be a URI" constraint in the
BPSS document? Or is it?
Dale Moberg wrote:
The
version 2.0 CPPA does not document Role as
being obtained from the xlink:href attributeon
the CPPA Role element. Rather the xlink is documented
as a pointer into theXML
where the Role is defined.After
version 1, a number of questions remained about aligning BPSS values
withMSG
values, especially for Service, Action, Role, retry, etc. Brian, Hima,
Arvola, Pallaviand
others identified residual issues. Not the place to review all this, but
for "Role" hereis
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 enforcethis
datatype and instead chose to make the "name" attribute type xsd:string.
This wasas
close as the alignment of MSG and BPSS got. I think nameId, of type ID,
is notfor
MSG consumption. CPPA did use it in the xlink reference to the place in
the BPSSinstance
where a Role value is defined. The point was that because the "name" attributewas
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
ofthe
CPPA's AII in Role/@name (as approximately
found in Appendix F). I think weneed
to be more explicit in both Appendix F table and the text though so Cliffdoes
not have to support both values. I think IIC should probably put thisin
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 isthat
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 whichis
a "CF certified good thing(tm)" However,
I think Chris's thought only made it
as far as supportinga
"should be URI" in the messaging spec. Dale
Moberg
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
...
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC