OMG, that XEP is extremely and unnecessarily complex. Just do, I don't know, markdown.

That made me remember IBM JSONx... https://www.ibm.com/docs/en/datapower-gateway/10.6.x?topic=2...

▲ F3nd0 4 hours ago | parent [-]

What’s so complex about it? From what I gather (after skimming the document just now), you attach an extra element to a message which says how to style which parts of the message, from codepoint n to codepoint m, essentially. At least conceptually, that seems really simple and straightforward.

Are there more elegant or natural ways to do it? Probably. But when you say ‘extremely complex’, saying ‘codepoints 7 to 15 should be bold’ is not what comes to my mind.

▲ dale_glass 2 hours ago | parent | next [-]

Things I don't like:

* It's not standard. You can't plug in some normal formatting library there and be done with it.

* You'll probably end up having to write conversions back and forth.

* It's fragile -- if anything gets misaligned it'll break

* It's tooling unfriendly. Think things like Nagios, Grafana, etc sending formatted notifications. Everything can do this or <b>this</b>, but practically nothing is set up to accommodate this format.

* It leaks into other subsystems. You can't eg, just search/replace/insert/delete words if you need to for any reason without breaking this.

Is it the worst thing ever? No, but it seems to go with the pattern that nothing in XMPP is normal or comfortable. Everything has this weird particular flavor to it and more complexity than necessary.

If it were up to me, my option would be to support 2 things: Markdown for simple cases, and embedded HTML for when you really have to get fancy. Each of those can be handed out to existing code and you don't ever have to keep adding extensions because what if people want colors or something now.

	▲	Groxx an hour ago \| parent [-]
		None of this seems particularly different from doing <i>spans</i> inline (what if you forget to close one? or they overlap?), but it has a major benefit of being very backwards compatible, supporting future variants in parallel for gradual migration, and doesn't require any changes to search tools. And separating markup instructions from content is generally a very good idea. And you could use markdown. Just get the rendered spanned text result and transpile it. This would be true for any editor as well, just get convert it to spanned text, edit, convert back. And with HTML you'll still have to specify what subset you support, and many tools won't support that either. Markdown suffers from this too, by supporting embedded HTML, though at least commonmark is pretty baseline and well supported.

▲ amenghra 3 hours ago | parent | prev [-]

The following example (from the spec) seems quite fragile:

    <message>
      <body>This XEP supports many things:
    * inline markup
    * code blocks
    * lists
    * and possibly more!</body>
      <markup xmlns="urn:xmpp:markup:0">
          <list start="31" end="89" ordered="false">
          <li start="31"/>
          <li start="47"/>
          <li start="61"/>
          <li start="69"/>
        </list>
      </markup>
    </message>