Re: EXI LC Comments

Dear Youenn,

Thank you for your feedback.

> 4)  Typed encoding in schema-less mode
>
> EXI enables limited typed encoding support in schema-less encoding.
> Since only predefined types are supported, xsi:type seems mainly useful to
> encode base64 chunks with the binary encoding.
>
> Even in that case, the usability is not so good : in some  cases, elements
> whose content is base64 have also attributes. For instance ds:SignatureValue
> has an optional ID attribute.
>
> Of course, one could still use xsi:type=base64Binary in deviation mode but
> interoperability may be pretty bad and putting a wrong xsi:type for the
> purpose of compression seems broken.
>
> Also to be noted that:
>
>                 - Attribute values cannot be typed encoded with schema-less
> grammars.
>
>                 - Other useful types like "list of float","list of integers"
> cannot be used without external schema knowledge.
>
> Improved out-of-the-box support of this use case would be very helpful.

The comment you are making is accurate. Please let me try to give
you more information on our reasoning.

We feel that EXI should fit smoothly into the XML stack. To avoid any
problems EXI supports type information in the same fashion as XML
does. The groups intention is not to super-set XML. XML allows one to
specify typed-values with the attribute xsi:type. EXI provides the
same mechanism and both work on elements only.

EXI makes use of XML Schema and its types form the basis for typed
values in the entire W3C environment. Introducing new types or another
type system is not the scope of our group and might affect XML
processing in general.

A newly invented typing system would be processed in the context of
EXI only. Such type information would be lost when documents are
converted from EXI to XML then back to EXI. This may cause an issue,
since it may look like XML cannot preserve what EXI is describing.

The solution for arbitrary types in EXI (as well as in XML) is using
schema information.
Please note that partial schema information are sufficient for EXI. In
the use-case you provided a ds:SignatureValue element with the
according type information for content and attributes achieves the
desired result. An EXI processor picks the given type information for
element content as well as the attributes.

I hope this helps to answer you question and to explain our rationale

Thanks,

-- Daniel

Received on Monday, 29 December 2008 09:24:39 UTC