RE: EXI in XMPP: schema negotiations

Hi Daniel, Peter,

There may be more to define than uploading a XML schema document.
You probably need to take care of all include/import in a proper way so that everything is unambiguous.

Uploading a compressed XML schema document give benefits on the network side but it does not give any benefit on the processing side. Processing a schema document is generally difficult and will probably be restricted to XMPP servers? Having a simpler format would help (better compression, better processing) but would need some significant extra definition work.

As for QName and prefix preservation, whenever you have an attribute whose type is QName, the whole attribute value is encoded as a string (except for @xsi:type values). Therefore the decoder needs to know how to resolve the prefix that is embedded in the string representation to a URI. 
If preserving prefixes, you guarantee that the information is available to the decoder. 
But other alternatives, for instance conventions specifically defined to the XMPP environment, may be envisioned.

Regards,
	Youenn

> -----Original Message-----
> From: Peter Waher [mailto:Peter.Waher@clayster.com]
> Sent: jeudi 18 avril 2013 01:27
> To: Peintner, Daniel (ext); Rumen Kyusakov
> Cc: standards@xmpp.org; public-exi@w3.org
> Subject: RE: EXI in XMPP: schema negotiations
> 
> Hello Daniel
> 
> Thank you for your mail. I'll try to answer your comments one at a time:
> 
> > Hi Peter, all,
> >
> > My feedback comes rather late but I hope it is still useful.
> 
> All input is welcome. It's not late.
> 
> > 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.
> 
> I'll have to check my inbox. It seems I've missed his mail, and have to check his
> comments. Why do you think preservation of prefixes is necessary to decode an
> XML schema? Please elaborate.
> 
> > Also, the differentiation between the two contentType values "ExiBody" and
> "ExiDocument" is not really necessary. The overhead would just be one byte.
> 
> ExiDocument would be EXI header + optional EXI options (> more than 1 byte in
> the general case) + ExiBody.
> 
> > 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.
> 
> Thanks for this input. I've included this in the next revision.
> 
> > Hope this helps,
> >
> > -- Daniel
> >
> > [1] http://www.w3.org/2001/XMLSchema.xsd
> >
> > External service provider at Siemens AG
> > 81739 Munich, Germany
> 
> It certainly does, thanks for the input, Sincerely, Peter Waher

Received on Thursday, 18 April 2013 07:00:21 UTC