MTOM, constraints on nodes types

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