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.