W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Describing which blobs are to be optimized.

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 15 Jun 2004 19:07:06 -0400
To: "Jonathan Marsh" <jmarsh@microsoft.com>
Cc: www-ws-desc@w3.org, xml-dist-app@w3.org, xml-dist-app-request@w3.org
Message-ID: <OF8C09F97A.8F07F5D6-ON85256EB4.007F2B14@lotus.com>

Jonathan Marsh writes:

>> P.S.  for XMLP: It's a bit disconcerting to see a "MUST NOT" in a "Note".

FWIW:  I could easily live with making that a lowercase "must not".  I 
believe it is (intentionally) redundant with normative rules given 

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

"Jonathan Marsh" <jmarsh@microsoft.com>
Sent by: xml-dist-app-request@w3.org
06/15/2004 06:45 PM

        To:     <www-ws-desc@w3.org>, <xml-dist-app@w3.org>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: Describing which blobs are to be optimized.

My reading of the straw polls [1] relative to Issue 207 leads me to
suggest the following resolution:

Ask the XMLP WG to augment the paragraph in MTOM
[http://www.w3.org/TR/soap12-mtom/#aof-sending] as indicated {{thus}}:

"Note: the means of identifying element information items that contain
base64 encoded data in canonical lexical form are
implementation-dependent. Some implementations can identify such element
information items by construction (e.g., because a certain API may
create only canonical forms); others may check the characters prior to
sending{{, others may rely on information in the description such as the
presence and/or value of the xmlmime:expectedMediaType schema annotation
[reference to XMLMIME]}}.  Because of the need to exactly preserve the
characters in the transmitted Infoset, non-canonical representations
MUST NOT be optimized."

 [1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0128.html

P.S.  for XMLP: It's a bit disconcerting to see a "MUST NOT" in a
Received on Tuesday, 15 June 2004 19:10:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:41 UTC