[Standards] Markdown in XMPP IM

Peter Waher peterwaher at hotmail.com
Fri Jan 8 02:05:27 UTC 2016


Hello all
 
Regarding the recent comments:
 
> > > 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).
 
It's an overly pessimistic view on things. It's a simple IF, to decide where to take the information from, if you understand the content type. From the body (if the element is empty) or from the element itself (if not).

> 
> 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.
 
No it does not. Since I sparked the thread I encourage you to read my comments in the beginning.
 
> > 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.
> 
> it's ugly and messy in my opinion. We already have 2 syntaxes: text for client 
> we can't or don't want to display rich content (e.g. console client), and 
> XHTML-IM for rich content.
 
Then don't. I don't propose doing this as mandatory for clients to support. The question is, IF clients want to send markdown, should it be done in a proprietary fashion, or should the XSF provide an interoperable means to do this? The XSF cannot block people from doing it, it can just choose to limit interoperability, in case people want to, or help interoperability, by providing a standardized means for how it should be done, if done at all.

> 
> If we start to use rich syntax for text content, which syntax should I use in 
> my client when both markdown and XHTML is there ? And what if clients start to 
> send markdown only messages ? And what about the flavours ?
 
I guess that is a question for other forums, for instance once dedicated to markdown.

> Markdown translates easily to XHTML(-IM) and the opposite works quite well 
> too.
 
No, it doesn't actually. Generating HTML from markdown is easy, but not markdown from HTML (or even knowing when received HTML is made from markdown at all and can be converted).

> 
> I think adding new syntaxes (non XML in addition, meaning that client need a 
> specific parser) is a bad path.
 
Only if they want to support this new syntax. If users want a markdown syntax in the chat client, then they would have to add a markdown parser, regardless if it's sent or not over XMPP. If users don't want to use markdown syntax, there's no need to worry. The only reason when you don't need to add a markdown parser, is if you create a bot sending markdown messages from code. But if you want to allow users to use markdown, you need a parser. If you don't want to allow users to use markdown, you're not forced to.
 
Best regards,
Peter Waher


 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160108/826c8ea6/attachment-0001.html>


More information about the Standards mailing list