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

AW: EXI in XMPP: schema negotiations

From: Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com>
Date: Wed, 17 Apr 2013 13:20:05 +0200
To: Rumen Kyusakov <rumen.kyusakov@ltu.se>, "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: <2DDEC868-FB95-4FD7-B244-DF22C26DC05B@mimectl>
Hi Peter, all,

My feedback comes rather late but I hope it is still useful.

I think having the possibility to upload a compressed XML schema document is very beneficial. That said, I agree with Rumen that in almost any case you need to have Preserve.prefixes on to allow proper decoding.

Also, the differentiation between the two contentType values "ExiBody" and "ExiDocument" is not really necessary. The overhead would just be one byte. Instead, I would propose having another alternative that may work well for many use-cases. The current default options point to no schemaId. A very efficient representation on the wire would be the schema for schema definitions [1]. These pre-shared grammars would largely reduce the size of the compressed XML schema stream.

Hope this helps,

-- Daniel

[1] http://www.w3.org/2001/XMLSchema.xsd

External service provider at Siemens AG
81739 Munich, Germany

________________________________
Von: Rumen Kyusakov [rumen.kyusakov@ltu.se]
Gesendet: Freitag, 22. März 2013 11:54
An: Peter.Waher@clayster.com
Cc: standards@xmpp.org; public-exi@w3.org
Betreff: EXI in XMPP: schema negotiations

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 Wednesday, 17 April 2013 11:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:47:17 UTC