RE: Proposed text for Base64-specific optimization

Noah,

I think I was listed as a co-actionee only because I originally
volunteered for this item. However, as I couldn't give it the required
attention to get it ready for today's call, it was assigned to you
instead. 

That said, I here's a baker's dozen of comments, some of which relate
directly to your proposal, others of which are more general.

Cheers

Gudge

General comments:

1.	I'm beginning to wonder what the value of the abstract feature
is. Given that its 'use' is hop-by-hop, I wonder why don't just spec the
serialization and transport pieces and be done. They are, after all,
what will provide interop. All the abstract feature gives us is a single
property that is not externally visible.

2.	I also wonder if it would be better to describe the mechanics
ONLY in terms of deserialization, much as we did for the SOAP encoding
in Part 2. Including the serialization details confuses things.

3.	I'm wondering whether our notion of binding is too monolithic.
It seems to me that it needs breaking into two parts: serialization and
transmission.


Specific

3.	Section 1.2. I'm concerned that the inserted sentence will lead
people to believe that they have to have the canonical lexical rep
around in the first instance, prior to serialization.

4.	Section 2.4.1. The inserted text before the two ed-notes doesn't
seem quite right to me. The means of optimization is in-scope ( you use
the include element/MIME part serialization ). It's the means of
determining which additional elements to optimize which is out-of-scope.

5.	Section 3.1. I'm not convinced that use of the inclusion
mechanism is optional.

6.	Section 4.3.1. I thought we decided in Sophia-Antipolis that
Content-Type would be multipart/related, at least for the 'outer'
packaging.


Nits

7.	Section 1.2 There is some text missing at the end of the
inserted sentence.

8.	Section 2.3. There is text missing at the end of the sentence
inserted into the second ednote.

9.	Section 2.4.1 s/reconstrcuted/reconstructed

10.	Section 3.3,2 s/xbinc:include/xbinc:Include ( for consistency )

11.	Section 3.3.2 Bullet 3. s/The serialization/each serialization

12.	Section 3.3.3 s/correpsonding/corresponding

13.	Section 3.3.3 s/reconstuction/reconstruction
 

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of 
> noah_mendelsohn@us.ibm.com
> Sent: 29 July 2003 23:58
> To: xml-dist-app@w3.org
> Subject: Proposed text for Base64-specific optimization
> 
> 
> 
> 
> 
> At the f2f I took an action item to propose text that would 
> more clearly indicate that our optimizations are, at least 
> for the moment, only for data that appears in the infoset as 
> base64Binary.  The attached html file has proposed changes, 
> highlighted as marked revisions (blue).
> 
> In the intersest of full disclosure, there are a few other 
> editorial changes in this version.  I had started hacking on 
> these in my role as an MTOM editor on the plane to France, 
> and decided to leave them in this copy.
> I think it will be clear which changes are related 
> specifically to my action and which don't.  The ones that 
> don't have no official status.
> Insofar as they are indeed editorial I may propose to the 
> other editors that we adopt some, but as always comments are 
> welcome.  If any concerns are expressed by WG members about 
> any of these we will definitely hold off.
> 
> Bottom line:  the majority are base64-related, and those are 
> the ones you should focus on.  Comments on the others are welcome.
> 
> I notice in the agenda for tomorrow that Gudge is listed as 
> co-actionee on this.  I hadn't realized that, and he hasn't 
> seen this.  So, he may or may not agree.  Finally, the action 
> is listed in relation to issue 432, but this text deals only 
> with the part of 432 that has specifically to do with base64, 
> which I believe was the scope of my action.  I believe my 
> action is thus fulfilled, but I don't think we can close 432 
> based on this text alone.  Thanks!
> 
> (See attached file: SOAP Message Transmission Optimization 
> Mechanism w Noah Edits for Issue 432.htm)
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
>

Received on Wednesday, 30 July 2003 05:23:27 UTC