W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > January 2008

Re: ACTION: 115 on EXI.

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 29 Jan 2008 15:36:33 +0100
To: Juan Carlos Cruellas <cruellas@ac.upc.edu>
Cc: XMLSec <public-xmlsec-maintwg@w3.org>
Message-ID: <20080129143633.GB3549@iCoaster.does-not-exist.org>

To make tracker keep the record, these messages were both about
ACTION-115.

;)
-- 
Thomas Roessler, W3C  <tlr@w3.org>






On 2008-01-29 15:06:36 +0100, Juan Carlos Cruellas wrote:
> From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
> To: XMLSec <public-xmlsec-maintwg@w3.org>,
> 	Juan Carlos Cruellas <cruellas@ac.upc.edu>
> Date: Tue, 29 Jan 2008 15:06:36 +0100
> Subject: ACTION: 115 on EXI.
> List-Id: <public-xmlsec-maintwg.w3.org>
> X-Spam-Level: 
> Archived-At: <http://www.w3.org/mid/479F32EC.2050506@ac.upc.edu>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
>
> 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.
>
>

On 2008-01-29 15:33:24 +0100, Juan Carlos Cruellas wrote:
> From: Juan Carlos Cruellas <cruellas@ac.upc.edu>
> To: XMLSec <public-xmlsec-maintwg@w3.org>
> Date: Tue, 29 Jan 2008 15:33:24 +0100
> Subject: ACTION: 115 on EXI (II)
> List-Id: <public-xmlsec-maintwg.w3.org>
> X-Spam-Level: 
> Archived-At: <http://www.w3.org/mid/479F3934.2090906@ac.upc.edu>
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.6
> 
>
> Dear all,
>
> In my previous message you may read:
>
> "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 fact from the reading of the spec I can not firmly conclude that the tables are populated in the EXI stream, as the text merely says "are populated"...
>
> So the sentence should read:
> "
> "If such option is set then EXI processors assign to the literals short 
> codes that are matched to the literal values in tables "
>
> Regards
>
> Juan Carlos.
>
>
>
Received on Tuesday, 29 January 2008 14:36:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 29 January 2008 14:36:45 GMT