[ebxml-msg] FW: some problems with MAY?

[David Fischer <david@drummondgroup.com>]

Attached are some comments about our use of MAY.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: jacques [mailto:jacques@savvion.com]
Sent: Monday, October 29, 2001 12:42 AM
To: David Fischer
Subject: some problems with MAY?


David:

This is just something I noticed when going through MS 1.05, and that
I think could be ambiguous for some developers.

- Jacques Durand



I noticed the keyword MAY is used in places of 1.05 where it could really 
be ambiguous for implementors:

In several places, it is used to describe an alternative:
(1) “...MAY use/do either A or B...”
where , I guess, you really meant:
(2) “...MUST use/do either A or B...” 
In other words, the “may” should not be normative here: 
it is only to be taken in the common sense, but 
should then be complemented by a MUST:
“... may use either A or B, but MUST use one of them.”
Because if it is normative, then (1) really means that you may as 
well NOT use A or B at all (as the group “either  A or B” is optional itself, 
according to the keyword definition...)

A few examples below from 1.05 illustrate the use of the normative MAY, 
to describe an alternative, where I believe a MUST should have been used instead. 
This may be very misleading to implementors:  


Example #1:
“...Support for Reliable Messaging MAY be implemented in one of the following two ways:
- using the ebXML Reliable Messaging protocol, 
- or using ebXML SOAP structures together with commercial software products that are 
designed to provide reliable delivery of messages using alternative protocols.”

Example #2:
"...The AckRequested element MAY be targeted at either the Next MSH or the To Party MSH"

Example #3:
“…The From and To elements MAY also contain zero or one Role child element that,…”

Example #4:
"...The Description element MAY be present zero or more times as a child element 
of MessageHeader..."


In some other cases, it could be that a simple literal “may” was sufficient 
if there is no strong normative requirement but a kind of explanation instead 
(but the MS TC is the judge here), which I suspect could be the case in:

Example #5:
“…Payloads MAY be a simple-plain-text object or complex nested multipart objects….”

Example #6:
“…MAY be included in the SOAP Envelope, Header or Body elements, or directly in each 
of the ebXML SOAP extension elements.”