Re: Messaging Service spec v0-2 COMMENTS

[Jon Bosak <bosak@boethius.eng.sun.com>]

Here are some things I noted as I read through this fine piece of
work.

line 168

   If I understand this correctly, it should read "that are
   associated with the two MIME parts" rather than "associated
   with a MIME part."

lines 170-172

   are confusing.  I would rewrite them as follows:

      An ebXML Header Document is the content of the first MIME part
      in a Message Envelope and the ebXML Payload Document is the
      content of the second MIME part.

   (A message per 161-165 can have only these two parts, right?)

lines 174-176

   Is this just echoing something in an existing spec?  If so,
   I think that should be noted.

lines 202-210

   This seems to set up a zero-based versioning system unlike the
   one-based system that's used later in 257-260.  Can we pick one
   or the other to use in both cases?

   Introducing the concept of a "version-less message" (205-206)
   to which all implementations must conform and then declining to
   define what that means (208-209) suggests that you think the
   system will be stable enough at some point to go back and agree
   on what (by then) constitutes its invariant features.  Is that
   about right?

lines 216-219

   Is Content-Length really necessary, or is it in here on general
   principles?

lines 298-300

   Is this the same as saying that the structure of a payload is
   limited only by the capabilities of MIME multipart/related?  If
   so, that might be a good way to put it.  And then you could put
   in a sentence or two to describe what this means.

lines 327-328

   There is some equivocation here around the term "element."  I
   think it should just mean "XML element," in which case these
   lines could be rewritten thus:

      The ebXML Header Document is a single [XML] document
      containing a number of XML elements.

lines 351 and 353

   The terms "MessageManifest" and "MessageHeader" appear to be
   mistakes for "Manifest" and "Header".  Are these left over from
   some previous edit?

   Line 353 also appears to lose track of the sense of "required"
   in this context.  We are told that the MessageHeader (= Header)
   "contains the information REQUIRED by the recipient to process
   the message."  Here the word "required" is not normative but
   merely descriptive and should therefore be set in lowercase
   characters.  So too the "MUST" in line 1272 (which is a good
   thing, as the appendix itself does not appear to be normative).
   This same confusion appears the other way around in line 390,
   where "required" should be changed from lowercase to upper.

line 372

   The section number is missing.

lines 374-380

   Line 374 states that DocumentReference "is a composite element
   consisting of two required subordinate elements" and then
   376-380 immediately list three elements, one of them optional.

line 434

   "It [ServiceInterface] is unique within the domain of the Party
   to which the message is being sent."  Shouldn't this read
   "SHALL BE unique" or "MUST BE unique"?

line 435

   "URNs MAY be considered suitable for the element content."
   Does this suggest that they should ever be considered
   unsuitable?  Under what circumstances should this not be a URN?

line 466

   refers to "a single attribute, DeliverySemantics," but the
   example here and the DTD in line 577 show that
   DeliverySemantics is an XML element, not an attribute, and that
   it has siblings, TimeStamp and RefToMessageId.

APPENDICES

I didn't get deeply into Appendices A and B.

line 1264

   XML stands for "Extensible Markup Language," not "eXtensible
   Markup Language."

lines 1301-1304

   I think that this paragraph wants to be italicized like the
   three above it.

Jon