My recollection was that Role was introduced so as to
a) support RosettaNet better and b) to make it easier to
map the incoming message to a process state in the
choreography (BPSS) referenced by the CPA.
I believe that "optional" in the case of Role was
referenced to its cardinality (e.g. a message need
not contain a Role element under To and From).
However, a receiving MSH would have to be able to
receive a message that contained this information.
It doesn't have to use it, but it cannot fault if
it gets one.
IMO, it is only optional w/r/t whether the application
choses to supply this information (and/or consume it)
it is NOT OPTIONAL to support from an implementation's
perspective. However, the *nature* of that support
is certainly up to the implementation/vendor beyond
the ability to receive a message containing said element.
That said, I don't believe that this is an OPTIONAL
issue but one of cardinality.
Cheers,
Chris
Martin W Sachs wrote:
> So you are saying that it is OK for a software vendor to decide not to
> implement the ROLE element. Then each vendor has to supply a catalog
> stating which OPTIONAL elements he/she does not provide. A customer has to
> check every vendor's catalog to make sure that the OPTIONAL elements that
> the customer requires are supported. What if next month, the same customer
> discovers that he/she needs one more element that the newly purchased
> software doesn't support?
>
> Of course I can't believe that that is what you really mean. However a
> vendor that understands RFC2119 will interpret the MSG spec in exactly that
> way, Use of OPTIONAL for a purpose other than to indicate that a vendor
> doesn't have to support this particular major feature can lead to an
> interoperability disaster. One can eliminate the words OPTIONAL and MAY
> without changing any syntax or semantics.
>
> Regards,
> Marty
>
> *************************************************************************************
>
> Martin W. Sachs
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287; IBM tie line 863-7287
> Notes address: Martin W Sachs/Watson/IBM
> Internet address: mwsachs @ us.ibm.com
> *************************************************************************************
>
>
>
> David Fischer <david@drummondgroup.com> on 02/14/2002 12:08:25 AM
>
> To: Martin W Sachs/Watson/IBM@IBMUS
> cc: Christopher Ferris <chris.ferris@sun.com>, ebXML
> <ebxml-msg@lists.oasis-open.org>
> Subject: RE: [ebxml-msg] Issue 15: Use of the word OPTIONAL
>
>
>
> Marty, I don't disagree with your premise. We do need to avoid the word
> OPTIONAL unless that is really what we mean.
>
> Doug/Chris' Issue 15 concerns OPTIONAL in relation to the Role element. At
> the
> bottom of the issue, it also says there are other instances...
>
> I just went through the document again and I don't disagree with any of the
> instances where we use OPTIONAL. Ping/Pong (w/ or w/o signature), Message
> Status, MessageOrder are all truly OPTIONAL items for implementers. The
> only
> one I'm not sure about concerns Transfer Encoding on HTTP (I'm too lazy to
> research this at this time of night).
>
> Outside of the definitions, we use the word *OPTIONAL* 13 times and
> *optional* 3
> times (twice concerning the id element -- which maybe is not truly
> optional).
>
> Perhaps the problem is in section 1.1.1 and our definition of OPTIONAL? It
> says:
>
> ... An implementation which does not include a
> particular option MUST be prepared to interoperate
> with another implementation which does include the
> option, though perhaps with reduced functionality ...
>
> which we do by supplying the NotSupported Error.
>
> Regards,
>
> David.
>
>