W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2004

Proofread of MTOM draft

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 19 May 2004 08:49:40 -0400
To: xml-dist-app@w3.org
Message-ID: <OF42A09577.CC47D1B2-ON85256E99.00453562@lotus.com>

I've just done a quick skim of MTOM, following up on XOP notes of last 
night.  I did not get to the media-type registration part.  Also:  I have 
>not< had time to proofread the following.  My meeting is about to start, 
and I want to get this sent out in time for review.   Apologies for any 
errors.

Most Important
--------------

* Section 3.2:  "When sending a SOAP message using the MIME 
Multipart/Related Serialization, the SOAP message Data Model is serialized 
as specified in [XOP] 4.1 Creating XOP packages. "  -> "When sending a 
SOAP message using the MIME Multipart/Related Serialization, the SOAP 
>envelope Infoset< is serialized as specified in [XOP] 4.1 Creating XOP 
packages. "

* Section 4.3.1:  "Generate a binding-dependent SOAP fault"  This seems to 
violate the rule in the SOAP binding framework that a SOAP binding must be 
capable of sending any legal SOAP envelope infoset.  The bullet as 
supplied seems to preclude, for example, sending a SOAP message that 
contains an error report showing a fragment with a xop:Include in it.  I 
would prefer to leave out this bullet, but I do realize that in so doing 
we make implementations a bit more complicated, and to handle a quite 
obscure case.  Still, I don't like the precedent that a SOAP binding can 
punt on sending any SOAP envelopes that prove inconvenient.  Maybe we 
debated this earlier and I forgot?


Editorial or minor
------------------

* Section 1.2: "The implementation of the abstract feature as a binding 
feature for an HTTP binding is intended to enhance the SOAP HTTP binding 
described in [SOAP Part 2] 7. SOAP HTTP Binding or an updated version of 
it. "  This wording seems clumsy, but I don't have time to propose 
alternative.

* Section 1.2: "the specification described herein fulfills these 
requirements" maybe should be "the specification described herein fulfills 
>those< requirements"?

* Section 2.3.4:  "The choice of whether to implement such cooperation, 
and if so the means used, is at the discretion of the binding 
specification(s) and/or the implementation of the bindings. properties." 
Remove trailing word "properties".

* Section 2.3.4: "Other bindings may be capable of optimization, but may 
or may not choose to or succeed in optimizing the same portions (if any) 
that were optimized in the inbound message."  Grammar.  Parses as 
"bindings...may or may not choose to...optimizing".   Suggest "Other 
bindings may be capable of optimization, but may or may not >choose to 
optimize< the same portions (if any) that were optimized in the inbound 
message. "

* Section 3.3, 2nd para:  "incorrectly" is spelled incorrectly

* Section 4.3:  "the XOP Infoset build" -> "the XOP Infoset built"

* Section 4.3.1.1 (2nd bullet  in first list):  "extracted binary parts 
MUST NOT be referenced with more than one xop:Include in the SOAP message 
part. " -> "extracted binary parts MUST NOT be referenced >by<more than 
one xop:Include in the SOAP message part. "  Not important, but saying 
"reference with" seems a bit clumsy.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Received on Wednesday, 19 May 2004 08:50:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:18 GMT