W3C home > Mailing lists > Public > xmlp-comments@w3.org > January 2004

MTOM, constraints on nodes types

From: Herve Ruellan <herve.ruellan@crf.canon.fr>
Date: Thu, 29 Jan 2004 16:47:30 +0100
Message-ID: <40192B12.4030200@crf.canon.fr>
To: xmlp-comments@w3.org

Dear all,

- Context
Currently, section 3.1 [2] of MTOM [1] states:
<current>
For use with this serialization, the type property MUST be set to 
xs:base64Binary only for those Element Nodes known to be in the 
canonical lexical form for that type. The type property for all other 
Element Nodes MUST be set to xdt:untypedAny.
</current>

- Problem 1
In the last sentence, "all other" refers to Element Nodes whose content 
is not base64-encoded data in canonical lexical form.

I think that the current constraint on those Element Nodes is too 
strong: the only thing we need to ensure is that for those "other" 
Element Nodes, their type property is not set to xs:base64Binary.

A use case where the current constraint is inconvenient is when a user 
wishes to send a full fledged Data Model with precise type information 
on all the Element Nodes (for example a Data Model resulting from a 
query in a database). In such a case, with the current formulation, the 
user would have to remove all type information from his Data Model 
(expect for xs:base64Binary typed Element Nodes) before sending it with 
an optimized SOAP binding.

- Problem 2
Moreover I think that the first sentence may be somewhat unclear about 
our real intent. I think we want to allow for Element Nodes with 
base64-encoded content in canonical lexical form NOT to be tagged with 
an xs:base64Binary type. In such a case, the Element Node will not be 
optimized.

- Proposal
Therefore I propose to remove those two sentences as I think that 
sufficient constraints are described in 2.3.1 which is refered to just 
before those sentences.

Hervé.

[1] http://www.w3.org/2000/xp/Group/4/01/MTOM-WD/OptimizationMechanism.html
[2]
http://www.w3.org/2000/xp/Group/4/01/MTOM-WD/OptimizationMechanism.html#im-introduction
Received on Thursday, 29 January 2004 10:52:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:08 UTC