ACTION: 115 on EXI.

Dear all,

Below follow my understanding of EXI spec and some initial 
considerations based on my understanding of that and that in my opinion 
could be relevant to XML Signature.

EXI defines a XML representation for XML documents or fragments. It uses 
XML Information Set.
Actually, it defines to ways for getting the XML representaiton of a XML 
document or fragment:

1. One for documents/fragments whose structure is not defined anywhere 
(i.e. their structure is not defined neither by a DTD nor by a xml schema)

2. One for documents/fragments whose structure is defined in a DTD or a 
xml schema.

The XML representation (EXI stream) includes a EXI header and a EXI body.

The EXI header includes a field options. Among them, one finds the 
so-called "Fidelity Options". They serve to instruct the EXI to keep or 
to eliminate from the resulting EXI stream comments, Processing 
Instructions, DOCTYPE, Namespaces, and lexical values of elements and 
attributes values

And here there is a first implication:

EXI processors may generate XML representations that eliminate 
namespaces, that substitute lexical values of the elements and 
attributes by codes computed on the fly and shared by both EXI 
processors (generator and recipient) through tables.

The EXI body is generated based on the occurrence of the so-called 
"events": the presence of an element is taken as the occurrence of a 
"start element" event followed a fter awhile by the occurrence of the 
corresponding "end element", and so on.

Each event is assigned a certain code. EXI processor encodes each event 
by the sequence: Event Code Event content encoding.

EXI specifies encoding for basic types defined in XML schema 
(xsd:base64Binary, xsd:boolean, xsd:integer, xsd:string, etc).

EXI allows to shorten or optimize the encoding of literals that are 
repeated through the document, be they element or attribute values, 
local-names elements, namespace prefixes or namespace uris.
If such option is set then EXI processors assign to the literals short 
codes that are matched to the literal values in tables that are 
populated in thte EXI stream.


In case of no xml schema or DTD defining the structure of the document, 
EXI defines a number of initial default rules (Built-in Grammars in EXI 
terminology) which are used by EXI processors for generating and parsing 
EXI streams.

 From what I have mentioned before and my understanding of the document, 
the issues that relate with XML sig are:

1. The fidelity options that may change the encoding of the literals, 
which include literal values of element content or attributes, 
local-names of elements as well as namespaces prefix and uris. Although 
these codes are matched to the literal, the issue of how to secure the 
tables reporting this match remains. EXI spec uses the verb "populated" 
but I was not able to clearly identify how these tables should be populated.

2. In addition to that, no mention is done to special features that we 
have been dealing with during the last months: namely, what happens with 
special attributes (xml:base, xml:lang, etc..). No specific treatment is 
anticipated for their encoding in the case that some XML fragment is the 
result of a XPath transform.... and here the issue that EXI is dealing 
with XML Informatio Set whereas XPath results in a Node set could bring 
some interesting issues....

So far is what it has come to my mind after reading most of the EXI doc 
plus some examples.

I said "most" because I haven't had time to deal with the case when 
there exists a DTD or a xml schema. I plan to do it in the next days.


Regards

Juan Carlos.

Received on Tuesday, 29 January 2008 14:06:57 UTC