[Standards] XEP-0394: too weak to replace XEP-0071

Jonas Wielicki jonas at wielicki.name
Thu Mar 15 13:30:01 UTC 2018

On Donnerstag, 15. März 2018 14:02:41 CET Daniel Gultsch wrote:
> What intrigues me on something markdown ish (albeit probably something
> more than Styling currently has to offer) are its limitations.
> Particularity no color (that will never work in a federated
> environment where you don't know the design language and color scheme
> of the receiving application) and the lack of tables and such (tables
> will never work if you don't know the size of the displaying device)
> If we want to go with something more xml~ish I would prefer to
> annotate meaning (headline, importance, et al) instead of the
> availibilty of color and absolute font sizes and font family was
> something that annoyed me the most in XHTML-IM (despite the security
> flaws in the implementations)

Okay, so since I’m not going to get around to updating '394 this month and 
there’s considerable interest, I’ll write down what I have in mind:

* Emphasis, Strong emphasis, inline-preformatted (code)
* Enumerations
* Itemized lists
* Headings (two or three levels)
* Paragraphs
* XEP-0392-based colors (i.e. you only give a hue and the remainder is handled 
by the recipient)
* Code blocks with annotation of the language for optional receiver-side 
* Maybe inline images

Now there has been a lot of discussion around how to make this degrade 
gracefully. I’m thinking of the following:

Each markup annotation has a mandatory pre- and postfix in the body which is 
stripped once the markup is applied. That works like this (just a rough 
outline, don’t take the syntax for literal):

<body>This is the *new* markup.</body>
  <emphasis start="12" end="17"/>

Now <emphasis/> would be defined so that the selected range of <body/> MUST 
start with "*" and MUST end with "*". If-and-only-if (iff) that is the case, 
the prefix and postfix is removed and the text is displayed with emphasis 
applied on the word "new".

This is complex, and will not get less complex with more complex constructs 
like enumerations.

The reason for this complexity is that it allows a '393-compatible <body/> 
message, and also in general a good human-readable representation in clients 
which do not support it (if we chose the requirements well), while at the same 
time not allowing to "delete" arbitrary characters for some readers (it has 
been pointed out that this type of discrepancy can lead to problems).

So as a timeline, before updating '394, I want to:

- Draft an actual implementation of this scheme in JabberCat
- Figure out ways to represent the more complex elements

Unfortunately and as I mentioned, I have other priorities currently which is 
why this won’t happen this month. Sorry. However, I’d be interested in 
feedback to this approach and in general.

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180315/e88b2467/attachment-0001.sig>

More information about the Standards mailing list