[Standards] Markdown in XMPP IM

Ashley Ward ashley.ward at surevine.com
Thu Jan 7 12:59:33 UTC 2016


> On 7 Jan 2016, at 12:44, Peter Waher <peterwaher at hotmail.com> wrote:
> 
> Hello all
>  
> > If anything we should define a small microformat that looks good
> > formatted or in plain text (which could just be a specific Markdown
> > flavor minus the raw HTML stuff) and mandate that all clients that
> > support the spec use that one format.
>  
> Why define something new when there's a format that people like, know and want to use?
>  
> Furthermore, leaving the format out of the XEP allows standardization of the format to be done in other forums.

Agreed. And there is a standardisation effort for Markdown which will help the interoperability issue.

> 
> > 
> > So perhaps both approaches have their use cases? I don't fundamentally
> > object to either, but including multiple renderings in a
> > multipart/alternative style all the time just for improved handing of
> > *this* seems overkill.
> > 
>  
> What about an approach that allows both?
>  
> Say we create a new element <content type='...'/> that we send with the message. If it's empty, it could be considered a hint regarding the format of the message body. If it is non-empty, it contains an alternative, a formatted version of the plain text message body.

I think allowing alternate content renditions could be opening up a whole can of worms. We already have the body for plain text and XHTML-IM for rich text. If the plain text version happens to be structured then I think hinting as to the underlying format is useful (and I am definitely emphasising that it’s a hint to make the point that it can be safely ignored).

Some kind of type hinting solves the issue that sparked this thread, and I like the fact that it’s potentially not limited to markdown - you could imagine a system sending data in a yaml format for example, which is both human and machine readable. It’s also nice and simple.

—
Ash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160107/b3632322/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160107/b3632322/attachment.bin>


More information about the Standards mailing list