RE: [LC-2366] xs:nil feature simplification

Hi Youenn,
 
The WG has observed that while there are use cases that rarely use xsi:nil,
there are others that depend on it, some of which heavily to the extent that 
EXI's edge with regards to compactness hinges on taking advantages of it. 
Although we appreciate the points that you made and their potential benefits, 
we find it a bit difficult to graft them into the grammar system because 
certain things do not fit very well together. We exercised your idea as far 
as weighing the situation of having a behavioural mode that permits grammar 
generation and processors behaviour the way you described, however, we 
thought there will end up being another level of complication because of that. 
This leads us to think that it is hard to adapt the specification the way you 
suggested.
 
In addition, the WG has noted that the burden of implementing xsi:nil 
semantics for certain use cases using strict schema-informed grammars 
may not be as significant as it might seem. This is because AT(xsi:nil) 
productions are available only in element grammars that are defined explicitly 
as nillable in schemas. Even though your code still needs to be prepared for 
potential xsi:nil occurrences where the elements have been declared as 
explicitly nillable, the magnitude of which can be controlled by the way
schemas in use are written, and it could be reduced to even zero when your 
schema does not exercise nillable feature of schema at all.
 
Hope it helps,
 
-taki
 

  _____  

From: public-exi-comments-request@w3.org [mailto:public-exi-comments-request@w3.org] On Behalf Of FABLET Youenn
Sent: Friday, January 29, 2010 6:50 AM
To: public-exi-comments@w3.org
Subject: [LC-2366] 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