General EXI attributes handling

Dear all,

Based on internal feedback, I would like to make the following observations on the current EXI specification.
Note that this is not a request for change of the EXI specification.
I think however that this may be of some use/interest for the community.

Currently, all attributes of an XML element are stored by EXI encoders before being actually written.
This is a different behavior from text XML writers that can write attributes as soon as applications provide them.
In some environments, this attribute storage behavior has a real processing cost that does not appear with traditional StAX-like text XML writers.

There are two main technical reasons for storing attributes:

-          In schema mode, it is better to give specific attributes order so as to get good compression

-          @xsi:type and/or @xsi:nil must appear first in schema and schemaless modes
The first reason is a strong reason. I also note that EXI enables some flexibility in the attribute ordering if that better suits the application needs.  This seems very reasonable as this added flexibility does not impact performances nor interoperability.

The second reason seems weaker since, at least in our scenarios, @xsi:type/@xsi:nil do not appear very often anyway.
It would have been good to have the flexibility to put @xsi:type and @xsi:nil in the order desired by applications.
Of course, this would need changing the way these attributes actually impact on the EXI grammars.
I did not do the full exercise, but I am confident that there are some reasonably simple workarounds that would get us back to a similar functionality level anyway.

The advantages would have been:

-          No more special attribute behavior handling at the codec runtimes level

o   General spec simplification

o   Smaller and potentially faster EXI codec runtimes

-          Performances improvement by enabling streamed encoding of attributes

o   At least in the case of  built-in grammars but also in schema-deviation mode

o   More consistent with some text XML writer behavior

Regards,
                Youenn