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: 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
-----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

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