[Standards] Proposed XMPP Extension: Simple JSON Messaging

Jonas Schäfer jonas at wielicki.name
Wed Feb 19 17:15:19 UTC 2020


On Mittwoch, 19. Februar 2020 00:08:25 CET Marvin W wrote:
> The new XEP still uses the shortname "udt", has it in schema and also
> mentions UDT in the §2.2, without there being any description of what it
> means. I guess you just forgot to update those. This is likely to cause
> confusion if left like this (especially the one in §2.2).

Partially my fault. I only realised after the ship had sailed that I should 
not have accepted an overwrite of the file because it’s not versioned and now 
we cannot really compare old and new versions. Also, it’ll be confusing for 
anyone looking at the UDT thread back then.

> My only main critique that remains is that I fear using JSON inside XML
> on wire can become normal the more we specify around it.
> 
> I also imagine that by going down this route, people will soon ask for
> different notations like YAML (or TOML) to be supported.
> If that happens we also need to answer the question if we want to be
> able to convert between the different notations. And if we convert,
> between notations, which notation goes on the wire?

I’d like to note that TOML and YAML are not exchangable. YAML has a lot of 
crazy features not supported by TOML (or JSON, for that matter), such as 
recursive objects. TOML has a built-in datetime type, which is, AFAIK not a 
standard YAML feature.

So unless we build YAYAML which encompasses all those features (and please 
don’t), we won’t be able to make an abstraction here. And even if that wasn’t 
the case, I think we should KISS this.

> 
> Instead of allowing any of the three
> 
> > <payload xmlns="urn:xmpp:json-msg:0" datatype="urn:example:foo">
> > 
> >     <json xmlns="urn:xmpp:json:0">
> >     
> >         {
> >         
> >             "a b": [
> >             
> >                 {
> >                 
> >                     "c": 1
> >                 
> >                 }
> >             
> >             ],
> >             "d": "e",
> >             "f": null,
> >             "g": {}
> >         
> >         }
> >     
> >     </json>
> > 
> > </payload>
> > 
> > <payload xmlns="urn:xmpp:yaml-msg:0" datatype="urn:example:foo">
> > 
> >     <yaml xmlns="urn:xmpp:yaml:0">
> >     
> >         a b:
> >           - c: 1
> >         
> >         d: e
> >         f: null
> >         g: {}
> >     
> >     </yaml>
> > 
> > </payload>
> > 
> > <payload xmlns="urn:xmpp:toml-msg:0" datatype="urn:example:foo">
> > 
> >     <toml xmlns="urn:xmpp:toml:0">
> >     
> >         d = "e"
> >         
> >         [g]
> >         
> >         [["a b"]]
> >         c = 1.0
> >     
> >     </toml>
> > 
> > </payload>
> 
> we could just only go with something like
> 
> > <payload xmlns="urn:xmpp:object-msg:0" datatype="urn:example:foo">
> > 
> >     <object xmlns="urn:example:xoml">
> >     
> >         <list name="a b">
> >         
> >             <object>
> >             
> >                 <number name="c">1</number>
> >             
> >             </object>
> >         
> >         </list>
> >         <string name="d">e</string>
> >         <null name="f" />
> >         <object name="g" />
> >     
> >     </object>
> > 
> > </payload>
> 
> and have the client side handle the conversion to
> JSON/YAML/TOML/whatever. As this is all about people that don't
> understand what happens on the wire, they also shouldn't care if it
> really is JSON going over the wire, no?
> 
> Marvin
> 
> On 2/18/20 4:55 PM, Jonas Schäfer (XSF Editor) wrote:
> > URL: https://xmpp.org/extensions/inbox/udt.html
> 
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200219/fd69aef2/attachment.sig>


More information about the Standards mailing list