15.03.2018, 16:31, "Jonas Wielicki" <[email protected]>:

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: [email protected]
_______________________________________________

Reply via email to