[Standards] Standards Digest, Vol 146, Issue 10

Peter Waher peterwaher at hotmail.com
Wed Jan 6 20:42:03 UTC 2016

Hello Dave & Ashley, and others:

 > I'd be OK with having a namespaced attribute on the <body/> indicating
> markdown (with optional variant); the fallback to text seems reasonable
> enough.
> Ash's suggestion of an additional marker element is probably easier for
> most implementations to handle, though.
> Not particularly keen on an alternate body, since the only thing I can
> think of to sensibly degrade Markdown into is its source anyway.
There's a lot of things in markdown that you would prefer either removed or handled differently in plain text, such as links, inline HTML & HTML entities, inclusion of images, and if supported by the client, tables (which are often unreadable in text form, in text you want them formatted either using tab characters or spaces).

> Agreed. Markdown/yaml/whatever (and in theory all the ?text/*? content types) are readable as plain text (so entirely appropriate for a message body). The hint is there to tell clients that might be able to do a better rendition ?hey, this text body here is actually markdown? and give them an opportunity to render it nicely if they can.
Readable, but annoying.

> I?m happy to knock up a Content Type Hint ProtoXEP if anyone thinks it might be useful.
I would personally need another solution, so I would have to go with a separate content element, similar to the XHTML-IM case. Now, if the coucil says it's going to block any such proposal, I'll not send one. But if the coucil sees some value for the XSF in supporting interoperability of this kind, I'll of course send a proposal. If you Ashley want to contribute, we can write it together.
Best regards,
Peter Waher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160106/805354e4/attachment.html>

More information about the Standards mailing list