RE: Possible defect in XOP and MTOM

> -----Original Message-----
> From: xml-dist-app-request@w3.org 
> [mailto:xml-dist-app-request@w3.org] On Behalf Of Mark Nottingham
> Sent: Friday, August 26, 2005 12:45
> To: Alessandro Triglia
> Cc: Xml-Dist-App@W3. Org
> Subject: 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).


I respectfully disagree for two reasons:

1) since XOP references XML Schema, saying  "data not in the canonical
representation of the base64Binary datatype"  does not exclude the possible
presence of comment information items or processing instruction information
items intermixed with the character information items in the content of the
element, because XML Schema's validation process ignores those information
items (*).

2) the Introduction does not have normative force, and so it can only
describe in summary terms what the normative parts of the Recommendation
specify in a normative manner;  but there is no normative statement that
says that an element information item candidate for optimization "MUST" only
contain character information items.

I believe the normative text should state that the element information item
MUST only contain character information items, and those character
information items MUST be the canonical lexical representation of a value in
the value space of xs:base64Binary.

Alessandro


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


-------------------------------------------------------
(*)  

3.1.4 White Space Normalization during Validation

Throughout this specification, [Definition:]  the initial value of some
attribute information item is the value of the [normalized value] property
of that item. Similarly, the initial value of an element information item is
the string composed of, in order, the [character code] of each character
information item in the [children] of that element information item.

The above definition means that comments and processing instructions, even
in the midst of text, are ignored for all .validation. purposes.

[Definition:]  The normalized value of an element or attribute information
item is an .initial value. whose white space, if any, has been normalized
according to the value of the whiteSpace facet of the simple type definition
used in its .validation.:
-------------------------------------------------------



> 
> 
> 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
> 
>

Received on Friday, 26 August 2005 18:10:59 UTC