RE: EXI LC Comments

Hi Taki,

Following on your reasoning, I have one remaining question.
What happens in your scenario if the receiver tries to validate the decoded document (following a given mandatory validate-before-consume policy) ?
IIRC, the validator will get the xsi:type information and will try to see whether the schema construct pointed by its xsi:type value is valid against the validating schema. In the first example, this may be safe since we are using xs:base64Binary.
In the second example, the situation may not be as good. The newly defined type (base64BinaryItemType) will (in most cases) not have any derivation link with the schema validator supplied construct, hence a potential validation error.
I am not particularly aware on how are thrown xsi:type/schema matching errors, but even the first scenario may also face this issue.
One scenario which seems to fit with xsi:type optimization is when a given schema document constructs assign contents to anySimpleType or anyType.
If what's above is correct, this limits a lot the practical use of xsi:type for EXI optimization purposes.
Maybe I am pessimistic and overengineering all this but xsi:type has precisely defined semantics that need to be followed. Any insight is greatly appreciated.

Regards,
        youenn

-----Original Message-----
From: Taki Kamiya [mailto:tkamiya@us.fujitsu.com]
Sent: jeudi 8 janvier 2009 22:04
To: FABLET Youenn; 'Tatu Saloranta'; 'Daniel Peintner'
Cc: public-exi@w3.org
Subject: RE: EXI LC Comments

Hi Youenn,

I agree with you that it ought to be the application program that drops in
xsi:type type annotation into the infoset. Therefore the snippet you provided
would be better described like this:

  writer.writeStartElement('foo');
  writer.writeAttribute("http://.../XMLSchema-instance",  "type", "base64Binary");
  writer.writeBinary(blob,...);
  writer.writeEndElement();

Speaking of the second example you provided that involves the use of attributes,
I suggest to define a number of type definitions such as the one below for each
built-in datatype and share them in advance of the communication.

  <complexType name="base64BinaryItemType" final="extension">
    <simpleContent>
      <extension base="base64Binary">
        <anyAttribute namespace="##any" processContents="lax" />
      </extension>
    </simpleContent>
  </complexType>

You can then, use such basic types in your EXI instances.

  writer.writeStartElement('foo');
  writer.writeAttribute("unn:foo",  "type", "base64BinaryItemType");
  writer.writeAttribute('id','1');
  writer.writeBinary(blob,...);
  writer.writeEndElement();

It still has limitation with regards to the typing of attributes; attributes need to
be typed  in the schema, since xsi:type is not applicable to attributes themselves.

-taki

Received on Monday, 19 January 2009 15:45:24 UTC