On Thu, Sep 6, 2012 at 2:02 AM, Dave Cridland <[email protected]> wrote: > Oh, if you take it out of context like that, then yes... I was talking about > my suggestion of a removable prefix
Ok, my apologies -- I didn't realize it was sender-appended prefixes. Much like the "me" XEP-0245, where "/me " is a prefix transmitted as cleartext by the sender. In that case, I'm not sure I like the transmitted removable prefix idea, either. I generally prefer it be a recipient-appended prefix (if prefixes are used), not a sender-appended-and-transmitted prefix. I feel that implementations should decide how to highlight corrections and edits, and there's many completely reasonable ways to highlight edits (recipient-added prefixes, highlights, color codes, "Edited" tags, etc). For example, one implementation of doing things with XEP-0308 is that when edits are made, the message can also be moved orthographically to the bottom of the history and an "Edited" tag added. Enhancements in a specific client, such as selecting (or even mouseovering) the Edited tag, could possibly expand a list of previous versions of the same message and the timestamps for them. All of that can automatically be done by a client implementation, without modifications to XEP-0308. Then again, I also see the legitimacy of a removable prefix in backwards-compatible situations, including MUC (clients with and without 0308 support). As long as an algorithm is clearly defined for prefixes transmitted in XHTML-IM -- the simplest algorithm for prefix removal in XHTML-IM is simply iterate through the XHTML tree to the first non-blank innertext, and remove the leading prefix from it if a match for the prefix is found at the first non-blank innertext in the XHTML-IM tree. (I wonder if that's how XEP-0245 works over XHTML-IM?)
