xs:nil feature simplification

Dear all,

This is a mail about the @xsi:nil feature in EXI.
These thoughts are based on @xsi:nil implementation feedback, which is exactly what the CR period is all about.
Currently, similarly to @xsi:type, @xsi:nil may modify dynamically the grammar in use.

The EXI technology strives to get a good balance between simplicity and efficiency.
A sensible approach is to favor efficiency for usual cases and simplicity for the other cases.
For @xsi:nil, we think simplicity is better since this feature is rarely used in today's XML documents, at least in our environments.
In addition:

1)      the actual gain in terms of compression of the @xsi:nil specific behavior is small

2)      The cost within the specification is not small

3)      The cost (code size at least, possibly runtime speed also) within EXI codec runtimes is real

Our main issue with that feature is that it requires specific code not only at the schema mapping level but also at codec runtime level.
We would prefer this feature to be handled at the schema mapping level only.
It can easily be done by:

-          adding  @xsi:nil and EE productions wherever needed in strict mode

-          removing any specific @xsi:nil dynamic grammar modification behavior and compression mode specific rule (codec runtime level).

The downside is a small compression loss, but I do not think this is a real issue:

-          Compression loss would only happen when schema writers use nillable="true", which is not very common

o   In those case, the compression loss is not that high

§  At max, 1 bit for each instance of nillable="true" elements (due to one additional EE production).

§  This would happen only in strict/bit-packed/no-compression mode

-          When having a @xsi:nil="true" element, the compression loss is slightly higher

o   Additional encoding of a EE production

o   Additional SE entries make the last attributes productions index length potentially longer

§  It depends on the exact schema/XML instance

-          Schema writers are able to predict the cost of adding nillable="true" to their schemas

o   If worried about EXI compaction results, they may well find more compact alternatives for their schemas (minOccurs="0" e.g.).

Regards,
youenn

Received on Friday, 29 January 2010 14:50:16 UTC