On Samstag, 14. Oktober 2017 17:26:01 CEST Dave Cridland wrote: > - A new XEP handles a markdown-like syntax for IM.
(I’m repeating those parts of my arguments from the other thread against putting things in <body/> which apply against text-based markup in general.) (begin of copy) I still don’t think anything which is like markdown will cut it. The reason for this is that text-based markup is inherently hard to extend: Whenever you do some extension, you have to give a (sequence of) characters which formerly had no special meaning some special meaning (e.g. if we had Markdown without bold/strong before, we’d re-define **...** to mean boldface, where it had no special meaning before). This is unfortunate, and the only way out is to have a well-defined syntax which clearly distinguishes meta-symbols and normal symbols of text. Of course, a proposal like the ProtoXEP by Florian [3] (which is soon to be announced) helps with that because it allows us to version things. I’m however concerned how well that would work in practice (but I’ll raise those concerns when that ProtoXEP is discussed). (end of copy) Another thing I’d like to caution against is that using anything which resembles markdown too closely could lead to implementations just using a markdown parser. This has all the problems of markdown: (often) allows HTML by default, inconsistent specifications and featuresets, etc.. People will just slap on the closest markdown parser they can find and call it a day. Just like it happened with XHTML-IM. This gives us interoperability and potential security issues. Thus I propose to either specify something which isn’t like anything we had before (re-inventing the wheel for the purpose of having a proper protocol break) *or* using something which isn’t as ill-defined as markdown is (e.g. I think -- even though I haven’t checked -- that reStructuredText only has one specification. But rST also allows HTML embedding by default.). Daniel, I think we shouldn’t be pushing too fast in any direction here (by creating precedents) before we have some consensus. (Note that I don’t argue against using markdown or something similar as *input format*. I’m against using it in the transport.) kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
