Re: XOP/MTOM specs remaining problems

Noah,

Your proposal suits me very well.

My main concern on this part was to raise readers attention about errors 
that may occurs while trying to process a bad XOP Package.

Hervé.

[email protected] wrote:

>>4.2 Interpreting XOP Packages
>>
>>Issue: Nothing is said about what to do when the
>>reconstruction of the XML Infoset fails, or if the XOP
>>Package is incorrect while still allowing a
>>reconstruction of the XML Infoset (e.g., xop:Include
>>has a child element).
>>
>>Proposal: States that any failure is to be handled in
>>an implementation dependant way.  States that any non
>>fatal error may be ignored at the discretion of the
>>implementation.
> 
> 
> I have some concerns about this philosphically, in that I think it takes 
> us closer than necessary to implying that we are specifying the behavior 
> of processors as opposed to declaratively specifying an encoding. 
> 
> How about:
> 
> --------
> 4.2:  Interpreting XOP Packages
> 
> This section specifies the means by which the original Infoset can be 
> reconstructed from a XOP package that has been prepared according to the 
> rules of 4.1 Creating XOP Packages. 
> 
> Note:  conventions or error reporting mechanisms to  be used in processing 
>  multipart packages that incorrectly purport to be XOP Packages are beyond 
> the scope of this specification. 
> --------
> 
> The essential difference here is that instead of normatively specifying 
> that processors handle this in an implementation dependent way, we make 
> clear that anything beyond the processing of correct XOP packages is 
> beyond the scope of our specification.
> 
> Noah
> 
> [1] 
> http://www.w3.org/2000/xp/Group/3/06/Attachments/XOP.html#interpreting_xop_packages
> 
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
>