On Wed, Dec 4, 2013 at 10:48 PM, Peter Waher <[email protected]>wrote:
> XEP-0322 (EXI) contains two methods of using EXI-compressed XML in pure > binary form, i.e. not base-64 encoded. The first method contains a > handshake mechanism where a normal XMPP session is converted to pure binary > using EXI (including quick setup), and another mechanism which is EXI from > the start, i.e. no text XML is sent/received. > The mention of base64 (or not) in this instance was referring to the way a schema-aware EXI encoder will strip off the base64 from values which are declared as such in the XML schema, as I understand things, such as a hypothetical attribute value here: <foo attr='BLAHBLAHBL=='/> the attribute here in base64 would not be in base64 in EXI serialization. Feel free to correct me if I'm off the mark. > > > Having said that, some defense of XML: Using XML (either serialized as > text or serialized as efficient binary using EXI) has some exceptional > benefits, among other things its extensibility and interoperability. Being > able to use standardized techniques for validation (schemas), version > control and transformations (XSLT), searching (XPATH) etc. is a further > plus. There are many attempts to create “simpler” forms of communication > using for instance JSON, etc. But what is “simple” in the short term is not > necessarily what is simple in the long term, especially if you want to > create an interoperable infrastructure where myriads of service providers > share common networks and supposedly integrate with each other, taking into > account versions, contracts, etc. Making it too simple now, might end up > bury you in the end. > > There are designs for JSON schemas and JSON namespacing around, and even query languages too I think. For all I know there's an XSLT clone for JSON. In my opinion, these are classic examples of trying to make everything look like a nail - if you need all that kind of stuff, you probably need XML. Dave.
