On 10 April 2015 at 13:01, Dave Cridland <[email protected]> wrote: > On 9 April 2015 at 23:24, Ben Langfeld <[email protected]> wrote: > >> >> On 9 April 2015 at 16:58, Florian Schmaus <[email protected]> wrote: >> >>> On 09.04.2015 18:59, Ben Langfeld wrote: >>> > Florian, my concerns with your approach are twofold: >>> > >>> > 1. It is complicated and is not markup in the sense that is used by >>> XML, >>> > HTML, SSML, etc. Being abstracted means a complicated association step. >>> >>> Yep, it's more complicated then just adding another attribute to an >>> element surrounding text. >>> >>> Not sure what's the issue with it being not markup. In my eyes that's an >>> advantage here. >>> >> >> It is, conceptually, metadata for marking up part of the text body. I'm >> not sure what the motivation is for avoiding this idea. >> >> > It does mean you can have a plain-text body, which is quite nice; but I > think one could decide that any jid-like "word" was in fact a jid and fetch > vCard data for it, rendering it as the name, etc - with false positives for > email, and so on, of course. > > In other words, I might type: > > I talked to Romeo today. > > My client might note "Romeo" matched one of my contacts, and suggest I > meant "Romeo Montague". I affirm, and the message as sent is: > > I talked to [email protected] today. > > A smart(ish) client then get vCard data and renders: > > I talked to [Romeo Montague] today. > > Rendering Romeo Montague as a hyperlink, perhaps with a tooltip (or > similar) with the avatar, jid, and so on. > > This uses no markup (and no additional inlined metadata), and no > negotiation is required, but it's reliant on heuristics. >
And my concern with this is that the normalisation is not transparent for clients which do not support such de-normalisation of plain-text messages, which does not appear to be in Mel's list of requirements. I think this is where the point about data-* attributes not being understood by other clients comes into play; they would simply follow the usual rule of ignoring what is not specifically understood, though that might be better implemented using namespaced attributes to avoid conflicts. If such were used, would that contravene XEP-0071 or XHTML 1.0? > Sending: > > Romeo's email address is [email protected] > > ... might confuse things; luckily it must be very rare that an email > address has an identical-looking jid used by someone else. > > On the plus side, caching would work well here. > > Dave. >
