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: Comments on message header spec., v.0-63, 7/27/00


The earlier discussion was from me on the TRP list  couple of months ago.
That time, I was looking for advice on how to handle the "optional" problem
in tpaML.  Someone blew the train of thought by responding with a post
about the difficulties of conformance and no one ever responded to my

"Not required" would have the same RFC2119 difficulties as "optional" since
"required" is an RFC2119 word.  Explicitly mentioning cardinality is the
safest apporach although it can result in some pretty ugly sentence



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

Chris Ferris - Sun East Coast IR Development
<chris.ferris@sun.com>@xroads.East.Sun.COM on 08/09/2000 05:29:53 PM

Sent by:  cferris@xroads.East.Sun.COM

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   ebxml-transport@lists.ebxml.org
Subject:  Re: Comments on message header spec., v.0-63, 7/27/00


Some comments below. Thanks for the great feedback!

mwsachs@us.ibm.com wrote:
> Line 163:  This states "any additional header elements are optional".
> use
> of "optional" probably does not conform to RFC2119 since I assume that
> "optional"
> here means that the DTD specifies either "0 or 1" or "0 more more".  In
> RFC2119,
> "optional" means that an implementation may or may not support the

Yes, I've seen this same discussion elsewhere regarding use
of 'optional'. Can't recall whether it was transport or
architecture team which brought it up.

> In general, the term "optional" is problematical in XML with regard to
> RFC2119
> conformance because I find it very hard to write text about "0 or 1" or
> "0 or more" without using the word "optional". I went so far as to
> Roget's Thesaurus and could not find an acceptable synonym.  With regard
> "0 or 1" and "0 or more", an implementer should generally be required to
> support the tag.  I suggest modifying the RFC2119 conformance statement
> say
> "except for the word 'optional'" and to further state that when
> refers
> to a tag which may appear 0 or 1, or 0 or more, times, all implementers
> shall
> support this tag.  See tpaML draft ver. 1.0.6 for an example of such

Another approach we might consider is use of the phrase
'not required' to represent 0 or 1. Another approach might
be to explicitly call out the cardinality in the description.

element        cardinality
foo       0 or 1
bar       0 or more
baf       1 or more

Just a thought.

> Please scrub the spec for any other uses of "optional".
> Since there are currently no such optional header elements, as far as I
> tell
> from the DTD, an immediate solution is to delete the sentence containing
> this
> word at line 163.  However I recommend modifying the RFC2119 statement as
> above
> in order to be ready for the introduction of such optional elements.

Agreed. We'll have to see what the merged and revised revised
specification looks like to make any of these changes.

> Line 318:  What is "transport specific message"?  To me, a transport
> specific
> message is an acknowledgment or error message generated by the transport
> protocol and having no content to be processed by the application.  Such
> message won't have an ebXML header or envelope and will be sent on the
> connection created to send the message to which the ACK or error message
> responding.

Well, in part, this is correct. We should be more specific
and indicate that it is an ebXML Message Service specific message
as distinct from a transport specific message which as you rightly
point out is an ack or error reported via the connection
on which the message is sent.

An ebXML Message Service specific message is intended to
be asynchronous. It takes the form of an ebXML Message
(MIME multipart/related package with an ebXMLHeader body
part and an optional (0 or more) payload. The Acknowledgement
has no payload, whereas an error would have a payload,
yet to be specified, which contains the error information
(code, description or error text, context, etc.)

> Line 324:  What is "ebxml aware transport"?  This must refer to the
> system.


> To avoid confusion, I suggest that the word "transport" be used only
> to refer to transport-protocol functions (e.g. HTTP, SMTP) including the
> communication protocol and associated security functions at this level
> (e.g.
> SSL).


> Regards,
> Marty

                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Enterprise Architect - EMA
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903

[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