Section 2 is entitled "Deciding Whether or Not to Use EXI" and is almost empty. There's an ednote saying "This section will recommended [sic] a process (e.g., a decision tree) as guidance for determining the applicability of EXI in a given scenario/environment." Does the TAG want to say anything about this?
Section 4.1.1 suggests that EXI messages are not well-formed XML, which is certainly true, but contradicts some previous plans. This is the oldest document of the five, perhaps this has been overtaken. . .
Section 4.2 outlines the 'content encoding' approach to managing HTTP-based exchange of EXI-encoded messages. It is clear, but would perhaps benefit by acknowledging the difference between exi and e.g. 'gzip' as a content-encoding: gzip maps text to encoded text, and back again, whereas EXI as spec'ed maps infosets to encoded text and back again, so whereas a message which says "Content-Encoding: gzip; Content-Type: application/svg+xml" can be understood as saying "Unzip this byte-stream and you'll get a message body to which normal application/svg+xml processing can be applied", whereas interpreting "Content-Encoding: x-gzip; Content-Type: application/svg+xml" cannot be interpreted as saying "EXI-decode this byte-stream, and you'll get a message to which normal application/svg+xml processing can be applied", because the result of the EXI decoding algorithm is not a message body, it's an Infoset. I think the majority opinion has been that this is a fudge worth fudging, but perhaps (a) the tag should explicitly endorse it and (b) the EXI WG should acknowledge the fudge explicitly.
Beginning of section 3.2 refers back to a discussion of "the 'preserve' section of the EXI header", but this must be a copy-paste bug. . .
Section 3.2, 3rd para: should mention the need to preserve prefixes if there are QNames or XPaths in content in the document.
Section 3.3, last para before 3.3.1: Contradicts the first (correct) para, which points out that securing XML happens at the octet level. To say "securing a message takes place after its Infoset is produced and before it is serialized" is simply wrong -- it must be serialised before it can be encrypted or signed. You could serialize, sign, parse and then convert to EXI, but if that's what you mean you should say so.
If I read 4.1.2 correctly, it would be clearer to say "..., rather always use the application/exi media type, to allow a generic EXI processor to transform EXI into equivalent XML."
The references appear to go way beyond what is required -- another bit of unpruned legacy?
Between tables 2-3 and 2-4, "The preserve options shown in the table above" --> "The preserve option shown in the table above".
Table 2-5 needs to have the 'Structure' column explained.
Figure 2-1 is hard to understand. I figured it out because I'm familiar with XMill, but you probably need to say a bit about what you mean by 'content coding', and also how element and attribute identity are determined (or, alternatively, actually expand the figure to show this). The fact that the event names don't match up with those in table 2-5 is part of the same issue.
The discussion around and key in Figure 2-2 suggest that there are going to arcs coloured red as well as black, in fact it is arc labels which have differing colours. . .