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: [ebxml-msg] FW: some problems with MAY?




David Fischer wrote:

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


Good point, one or the other MUST be used. Replacing MAY above with MUST seems
appropriate.


> 
> Example #3:
> "...The From and To elements MAY also contain zero or one Role child element that,..."


I'm not so certain that MUST in this case would be appropriate. I wouldn't
object if others agree that use of MUST in this case (and others where
zero is an option) would be correctly understood/interpreted.


> 
> 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."
> 
> 
> 
> MAY_spec_issue.txt
> 
> Content-Type:
> 
> text/plain
> Content-Encoding:
> 
> QUOTED-PRINTABLE
> 
> 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC