[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.�