RE: EXI LC Comments

Hi Youenn,

If the receiver has a schema for validation use, the way to best explore
EXI encoding would be sharing the schema with the sender for encoding use.
Then there would be no unbalance between the types used for encoding, and
those used for validation in terms of schema information.

I think it is a good practice to define basic types such as base64BinaryItemType,
integerItemType, decimalItemType and so on, in parallel to xsd primitive types
in the schema. If you do so, you can use those types in elements where anyType
is expected per the schema.

-taki


-----Original Message-----
From: FABLET Youenn [mailto:Youenn.Fablet@crf.canon.fr]
Sent: Monday, January 19, 2009 7:45 AM
To: 'Taki Kamiya'; 'Tatu Saloranta'; 'Daniel Peintner'
Cc: public-exi@w3.org
Subject: 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 Tuesday, 20 January 2009 07:05:08 UTC