W3C home > Mailing lists > Public > public-exi@w3.org > March 2013

EXI in XMPP: schema negotiations

From: Rumen Kyusakov <rumen.kyusakov@ltu.se>
Date: Fri, 22 Mar 2013 10:54:08 +0000
To: "Peter.Waher@clayster.com" <Peter.Waher@clayster.com>
CC: "standards@xmpp.org" <standards@xmpp.org>, "public-exi@w3.org" <public-exi@w3.org>
Message-ID: <1A03301AB03E7941A3817570EB3FA19A22200A@STAEXDB2.staff.ltu.se>
Hello Peter, all,

Thank you for your comments on the EXI options exchange and adding the EXI compressed schema use case in the specification!
I think the text in section §2.5 captures the case and can be easily extended to incorporate new standard EXI schema formats when and if such become available.
Please consider the following comments:
- Predefining the EXI options to be used is very good approach as it simplifies the process and outweighs some small performance benefits that can be gained by for e.g. allowing communicating of the schema in EXI schema-mode.
- I agree with the choice of the default values of the EXI options except for preserve - most schemas use qualified names in attribute values (e.g. ref and type attribute when specifying a type definition). According to the EXI specification (section §6.3): "When qualified names are used in the values of AT or CH events in an EXI Stream, the Preserve.prefixes fidelity option SHOULD be turned on to enable the preservation of the NS prefix declarations used by these values". So Preserve.prefixes should be on or a large class of schemas will not be able to be presented by the EXI compressed schema mechanism.
- In my opinion the use of ExiBody and ExiDocument as a separate options of the compressed schema negotiations is unnecessary. When the EXI options are communicated in an out-of-band mechanism, which is the case of predefined options, the Options Presence Bit in the header can be set to 0 and the EXI Options omitted. Thus the difference in size of ExiBody and ExiDocument is 1 byte when EXI Cookie is excluded and 5 bytes otherwise. My suggestion is to merge the ExiBody and ExiDocument into a single option "EXI" and explicitly specifying that the options should not be included in the header as they are predefined. I am also in favor of implementing the same approach for the transmission of EXI-compressed stanzas. Instead of presenting them as a sequence of EXI bodies it is EXI standard compliant to transmit them as standard EXI documents with header and out-of-band options without including the optional EXI Cookie. This will make each stanza fully compliant EXI document with 1 byte header.
- I think the information on how the client and the server use the negotiated schema information is not enough and allows for ambiguous behavior by the implementations. The issue is that it is not clear which of the negotiated schema is the main one for a particular stanza - all others should be linked through the main one with <xs:import> statement. This is a standard way of defining constrains and validation checks for XML and is not unique to EXI - each XML can be validated against one XML schema at a time. This XML schema can have multiple namespaces added through <xs:import> and be spread in multiple files but there is a single root XML schema document from which all these definitions are linked. The unique identification of the root schema for each stanza is needed to correctly build the EXI body document grammar (http://www.w3.org/TR/2011/REC-exi-20110310/#informedDocGrammars) for which a list of all global definitions are needed. It might be useful to consider using the schemaID header option + the schema md5 hash for each stanza if other mechanism is not better suited.

Best Regards,
Rumen Kyusakov
PhD student 
EISLAB, Luleċ University of Technology
Received on Friday, 22 March 2013 10:54:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:44 UTC