OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: Use of Optional vs OPTIONAL

Gentle People,

Perhaps RFC 2119 is written from the viewpoint of implementors.  But please
remember, implementors come in many flavors.  And a specification (such as
an ebXML specificaton) may address more than one flavor of implementor.
Doug's "OPTIONAL"/"optional" suggestion really muddies the waters.  The
problem he tries to address isn't one of semantic meaning of the word
"optional", it is to whom the semantic meaning applies!  Using uppercase
"OPTIONAL" to apply to one group of developers (pehaps the middleware folks)
and lower case "optional" to apply to another group of developers (perhaps
the end-application folks) is definitely not a good idea.
Instead, the specification must make clear to which audience of developers
(or more precisely to which technical viewpoint) the constraint applies.


Relevant excerpts from prior Emails extracted below:

Doug writes:

Another way to describe David's proposal:
OPTIONAL - optional to implement for a compliant MSH
optional - (optional in the XML sense of the word) not required to appear in
an instance of the ebXML Header document or surrounding MIME headers

Marty chimes in:

Be careful even with MAY.  The sentence is clear but RFC2119 is mostly
about what implementers MAY or MUST do, so even that usage might be
interpreted as permissiveness with regard to implementing the function.

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC