Re: Message Header Spec - terminology

[srh@us.ibm.com]

Hi Marty,

|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).

So here goes more discussion on the standards world optionality issue. This
discussion has come up before, and always leaves me with considerable
concern.
I suggest that the biggest of these issues lies not with the RFC semantic
of "optional", nor with the
situation with an optional response to a "step" (using the current BP
metatmodel
terminology), but with the situation of vendor field support as you point
out.
This is actually not new to XML, but currently exists in the EDI world
also,
and I no of no way to fix it. We specifically discussed this in the OTA
(Travel Industry) XML consortium, and ended with a policy of pretty much
everything being optional. This is because it is usually difficult to agree
across businesses
on specific required fields (if agreement can be reached great), so the
default action is optional. If you make things required that are truely not
agreed upon as always needed, businesses will load garbage into those
positions.

You can let your mind wonder further on this problem. It was even discussed
that
a vendor may ask another vendor for their "modified" DTD/Schema, that
reflects
the real required fields for a specific vendor. Interoperability in this
context
is essentially destroyed.

Thanks,
Scott R. Hinkelman
Senior Software Engineer
XML/Java Solutions/Standards
Architecture and Development
IBM Austin
Office: 512-823-8097 TieLine: 793-8097
Home: 512-930-5675, Cell: 512-940-0519
srh@us.ibm.com
Fax: 512-838-1074



mwsachs@us.ibm.com on 04/26/2000 09:04:45 AM

To:   David Burdett <david.burdett@commerceone.com>
cc:   "ebXML Transport (E-mail)" <ebXML-Transport@lists.oasis-open.org>
Subject:  Re: Message Header Spec - terminology




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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   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?


Regards,
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
*************************************************************************************