RE: xsi:type, namespaces and preserving lexical values

Thanks for the comment.

As a general statement, the EXI specification states that, whenever QNames are encoded as strings, namespace prefixes should be preserved.  The working group clarified in the specification that this rule is also applicable for xsi:type values when preserving lexical values. Notes at the end of section 6.3 and 8.5.4.4.2 are addressing this issue in particular.

Interoperability issues may arise when prefixes are not preserved and xsi:type values are encoded as strings.
In particular, decoders and encoders may not be able to select the same grammar from the xsi:type encoded value.
Note that in such situation, EXI decoders are free to stop processing.
Coordination between encoder and decoder is generally required to solve that issue and share the same xsi:type value grammar retrieval mechanism at both sides. One could for instance imagine the out-of-band sharing of namespace bindings.

Regards,
                Youenn






From: FABLET Youenn
Sent: vendredi 29 janvier 2010 15:16
To: 'public-exi-comments@w3.org'
Subject: xsi:type, namespaces and preserving lexical values

Dear all,

This is feedback we have related to the EXI specification.

When preserveLexicalValues is true, @xsi:type should be encoded as a string, right?
In the case of preserving lexical values but not preserving namespaces (strict mode for instance),
the EXI stream will not contain any information about the URI of the @xsi:type qname value.
If that is correct, there is a potential issue:

-          Encoder has the URI information

o   Encoder will pick the grammar from the @xsi:type value (according the spec)

-          Decoder has not the URI information

o   It is not able to check whether there is a grammar associated to the @xsi:type value

o   Decoder will pick the default grammar (this my interpretation of the spec)
I am a bit surprised that  @xsi:type dynamic typing would not be usable when preserving lexical values in strict mode...
Anyway, the spec should probably align the EXI encoder behavior with the EXI decoder.

Regards,
                Youenn