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: Message Header Spec - terminology

I notice that the new message header spec draft states conformity to

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

I am considering doing likewise in tpaML but I am having trouble with the
word "optional".  RFC2119 clearly states that "optional" means that a
vendor is not required to support the feature under discussion.  Yet in the
XML world, optional is often used to mean that the tag has the * or ?  (0
or more;  0 or 1) qualifier.  I have many such cases in tpaML and it
appears that the message header spec is also using "optional" to mean the *
or ?  qualifier.

Roget's is no help with synonyms.  There are very few synonyms for
"optional" and none of them is attractive.

Finding a synonym for "optional" in any case not the whole solution.  In
tpaML, most optional tags must be supported by all vendors since a given
tag may be required in some applications and not in others or it may be
required in some places in the tpa and not in others.  (For those who have
looked at tpaML, an example is the action definition where in a given
application, some actions may have responses and others may not.)  Other
tags with * or ?  are optional in the sense that a given run-time vendor
may or may not choose to support a given tag. However, I think that those
tags would be required to be supported by authoring tools and by run-time
setup tools (so that a customer could procure a plug-in from a different
vendor when necessary).

At the moment, the only solution I can come up with is to put in the
RFC2119 conformance statement and qualify it with an explanation of
"optional", covering the above points and asking the reader to interpret
the word from context. I don't like that solution.

Does anyone have any suggestions?

Marty 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

[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