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

Philipp Hörist philipp at hoerist.com
Thu Mar 15 15:09:01 UTC 2018

Why would we make the body 393 compatible?

Is it too much to ask from developer to parse a markup tag and style the
string accordingly?!

we talk about max 5 lines of code here

start, end = getTag('emphasis').getAttrs()
string.addStyle('emphasis', start, end)

take this times 5 for the 5 elements 393 supports

thats an approximation
<https://dict.leo.org/englisch-deutsch/approximation> but
i dont need much more in GTK/Python3

So i dont really see the reason why i should add some backup body for
clients who dont support that.

2018-03-15 15:46 GMT+01:00 Kozlov Konstantin <yagiza at yandex.ru>:

> 15.03.2018, 16:31, "Jonas Wielicki" <jonas at wielicki.name>:
> 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
> highlighting
> * Maybe inline images
> It sounds promising. I just wonder why no links and no font customization?
> 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>
> <markup>
>   <emphasis start="12" end="17"/>
> </markup>
> 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).
> That idea is really interesting. An attempt to add compatibility to those
> two XEP's.
> But implementation <emphasis/> element like this without additional
> statements implies support of XEP-0393.
> IMHO it should be stated, that <emphasis/> element should be allowed only
> if other party explicitly supports not only XEP-0394, but also XEP-0393.
> Otherwise, it would be impossible to implement XEP-0394 without
> implementing XEP-0393, and XEP-0394 will be just an addition to XEP-0393.
> With my best regards,
> Konstantin
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180315/9a22d563/attachment-0001.html>

More information about the Standards mailing list