Re: Possible defect in XOP and MTOM

Besides the statements you quote, the Introduction says;

> Only element content can be optimized; attributes, non-base64- 
> compatible character data, and data not in the canonical  
> representation of the base64Binary datatype cannot be successfully  
> optimized by XOP.
While it's true that it doesn't say "XOP cannot optimise element  
children," I think that's covered by "data not in the canonical  
representation of the base64Binary datatype," which *is* limited to  
just character data (because we reference Schema datatypes).

That said, it might be helpful to add a clarification in errata, if  
the opportunity presents itself.

Cheers,



On 25/08/2005, at 2:20 PM, Alessandro Triglia wrote:

>
> Hi
>
> I am reading www.w3.org/TR/xop10/ and it seems to me that something  
> is missing in the following clause:
>
>
> -----------------------------------
> 3.1 Creating XOP Packages
>
> To create a XOP Package from an Original XML Infoset:
>
> [...]
>
> Identify within the Original XML Infoset the element information  
> items to be optimized. To be optimized, the characters comprising  
> the [children] of the element information item MUST be in the  
> canonical form of xs:base64Binary (see [XML Schema Part 2:  
> Datatypes Second Edition]3.2.16 base64Binary) and MUST NOT contain  
> any whitespace characters, preceding, inline with or following the  
> non-whitespace content.
>
> [...]
> -----------------------------------
>
>
> I would assume that the first condition to be imposed is that the  
> [children] of the element information item be all character  
> information items.  For example, comment IIs and processing  
> instruction IIs present among the [children] -- in any position --  
> should prevent the "optimization", as do the character IIs that are  
> whitespace.
>
> (That an element II present among the [children] should also  
> prevent the optimization is even more obvious.)
>
> Perhaps this condition is kind-of implied by the use of the term  
> "comprising" (instead of "among", say), but I think the condition  
> should be stated more explicitly.
>
> A similar problem exists in MTOM (clause 2.3.1).
>
> Regards,
>
> Alessandro Triglia
> OSS Nokalva, Inc.
>
>
>
>


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems