[Standards] Proposed XMPP Extension: JSON Content Type support

Evgeniy Khramtsov xramtsov at gmail.com
Tue Apr 26 11:39:48 UTC 2011


26.04.2011 21:28, Dave Cridland wrote:
> On Wed Apr 20 16:35:55 2011, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: JSON Content Type support
>>
>> Abstract: This specification defines JavaScript Object Notation 
>> (JSON) use in XMPP service.
>>
>> URL: http://www.xmpp.org/extensions/inbox/json.html
>>
>> The XMPP Council will decide at its next meeting whether to accept 
>> this proposal as an official XEP.
>>
>>
> And XEP-0292 isn't good enough?
>
> There's three problems I see with this.
>
> 1) It's extremely underspecified. '$' and '$$' are, for instance, 
> never specified.
>
> 2) This doesn't really mean that you don't need an XML parser, because 
> you still need to process XMLNS rules, etc. If you *don't* - ie, if 
> the JSON encoding expands all namespaces, then the data sizes will 
> increase vastly.
>
> 3) It's not at all clear to me that the mapping is truly reversible or 
> complete. I would expect each DOM node to have representation, and it 
> doesn't seem to be the case.
>
> I'm not a massive XML fan, to be honest. If we length-delimited 
> stanzas and used a clean header format, I'd be happier. But the fact 
> is that we *do* use XML, and removing XML entirely just seems like a 
> path without any clear merit.
>
> In particular, it's not clear what JSON encoded XMLstreams actually 
> gains us, given the limitations of the JSON encoded XML and the 
> prevelance of XML throughout the deployed network.
>
> Dave.

Agreed. Probably, if we need an XML replacement, it is better to choose 
another encoding scheme, not JSON.

-- 
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:xram at jabber.ru.




More information about the Standards mailing list