Re: [Standards] Marking up messages with metadata and XEP-0071
On 10 April 2015 at 13:01, Dave Cridland d...@cridland.net wrote: On 9 April 2015 at 23:24, Ben Langfeld b...@langfeld.me wrote: On 9 April 2015 at 16:58, Florian Schmaus f...@geekplace.eu 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 romeo@montague.example 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 romeo@hotmail.example ... 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.
Re: [Standards] Marking up messages with metadata and XEP-0071
On 9 April 2015 at 08:27, Kevin Smith kevin.sm...@isode.com wrote: 1) I’m not sure that adding data-* to XEP-0071 would aid interoperability, as the use of the data-* needs to be understood by both ends (e.g. in your case it isn’t enough for xep71 to just say ‘you can use data-*’, because a third-party client receiving your data-* markup wouldn’t understand what to do with it). Agreed. 2) As you’re controlling the clients at both end, I can’t immediately see any problem with just shipping data-* attributes inside the generated XHTML, although -71 says not to. The importance of following the specs is to ensure you can interop fully; if you’re controlling the clients at both ends and need special logic to do so you can add non-standardised markup reasonably safely. Adding a (private) disco feature and checking for it in caps would be better. Then, by all means, add custom attributes and markup. Not doing discovery/negotiation would mean a potential clash with clients you don't control; it also allows you to have multiple versions of your own clients deployed safely. As a rule of thumb, everything that XMPP does to allow interop between entirely different codebases also allows stability with multiple versions in a closed environment - you're not *really* controlling the clients totally at each end except in vanishingly rare, and very small-scale, cases. I’m not sure if others will agree or disagree with me here. /K
Re: [Standards] Marking up messages with metadata and XEP-0071
On 09.04.2015 06:10, Mel Adamaitis wrote: Problem: In an XMPP IM client we are working on, it is necessary for mentions of other users (for alerting, highlighting) to be based on a normalised user identity, but displayed in a denormalized human-readable format. Additionally, for a particular denormalized identity, there may be any number of normalised identities. For example, user j...@example.com mailto:j...@example.comshould be mentioned as Joe Bloggs. The relationship between the normalized and denormalized identities is known by the client authoring the message, and must be transmitted with the message for appropriate display and behaviour on the receiving end. I'm not sure if I would extend/modify xep71 for that use-case. If I had the requirement I would probably first try to mark the String and assign a semantic to the marked String by using an extra extension element: message… bodyHi Joe Bloggs. How are you?/body mark mention jid='j...@example.com' by-string string='Joe Bloggs'/ /mention /mark /message This has a few advantages: - It doesn't mess with xep71 - It also works with clients who do not support xep71, i.e. just 'body' elements. - It splits the marking and the assign semantic to mark in two different tasks The last point basically means that the features of this extension could be diverse. While I'm not sure if it's really a good idea to use it for for anything and everything, it's good to have the option: For example message… bodyWelsh looks like this: TI'n gallu ysgrifennu Cymraeg, ydy./body mark audio url='http://soundsoftheworld.com/welsh.mp3' by-range start='23' end='56'/ /mention /mark /message - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Marking up messages with metadata and XEP-0071
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. 2. It does not accurately correlate. Imagine this example: message… bodyHi Joe Bloggs. How are you? Oh, and you Joe Bloggs too?/body mark mention jid='j...@example.com mailto:j...@example.com' by-string string='Joe Bloggs'/ /mention mention jid='j...@example.com mailto:j...@example.com' by-string string='Joe Bloggs'/ /mention /mark /message That's a case where you would use 'by-range' in order to avoid the ambiguity. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Marking up messages with metadata and XEP-0071
On 9 Apr 2015, at 05:10, Mel Adamaitis melissamat...@gmail.com wrote: Problem: In an XMPP IM client we are working on, it is necessary for mentions of other users (for alerting, highlighting) to be based on a normalised user identity, but displayed in a denormalized human-readable format. Additionally, for a particular denormalized identity, there may be any number of normalised identities. For example, user j...@example.com should be mentioned as Joe Bloggs. The relationship between the normalized and denormalized identities is known by the client authoring the message, and must be transmitted with the message for appropriate display and behaviour on the receiving end. Requirements: • Allow a denormalized username to show up as highlighted/special when displayed in the client-side, up to and including unique selection in the DOM (for JavaScript). • Allow more than one denormalized username per message. • Allow non-unique denormalized username displays. • Continue to allow more text either before, after, or between mentions so that mentions can fit in with normal conversation flow. Current Solution: XEP-0071 allows for the span tag to have the following attributes: id, class, name, and style. We could misappropriate these attributes and do something like span class=”user-mention” title=”#ID#”John Smith/span. Complex data would have to be serialized somehow, and if you need to genuinely use all of the standard attributes currently allowed, there are none left to misappropriate. Proposed Solution: Update XEP-0071 to XHTML5 to allow the use of data-* attributes within elements. Does anyone see a flaw with this approach, or have an alternative suggestion which meets the requirements and/or which is already in use for similar functionality? I have two immediate thoughts (although maybe 8am isn’t the best time to try to think). 1) I’m not sure that adding data-* to XEP-0071 would aid interoperability, as the use of the data-* needs to be understood by both ends (e.g. in your case it isn’t enough for xep71 to just say ‘you can use data-*’, because a third-party client receiving your data-* markup wouldn’t understand what to do with it). 2) As you’re controlling the clients at both end, I can’t immediately see any problem with just shipping data-* attributes inside the generated XHTML, although -71 says not to. The importance of following the specs is to ensure you can interop fully; if you’re controlling the clients at both ends and need special logic to do so you can add non-standardised markup reasonably safely. I’m not sure if others will agree or disagree with me here. /K
Re: [Standards] Marking up messages with metadata and XEP-0071
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. 2. It does not accurately correlate. Imagine this example: message… bodyHi Joe Bloggs. How are you? Oh, and you Joe Bloggs too?/body mark mention jid='j...@example.com' by-string string='Joe Bloggs'/ /mention mention jid='j...@example.com' by-string string='Joe Bloggs'/ /mention /mark /message This obviously doesn't work, and is very much more complicated than simply permitting data-* attributes in the XEP-0071 security model (after updating to XHTML5, of course). On 9 April 2015 at 13:52, Florian Schmaus f...@geekplace.eu wrote: On 09.04.2015 06:10, Mel Adamaitis wrote: Problem: In an XMPP IM client we are working on, it is necessary for mentions of other users (for alerting, highlighting) to be based on a normalised user identity, but displayed in a denormalized human-readable format. Additionally, for a particular denormalized identity, there may be any number of normalised identities. For example, user j...@example.com mailto:j...@example.comshould be mentioned as Joe Bloggs. The relationship between the normalized and denormalized identities is known by the client authoring the message, and must be transmitted with the message for appropriate display and behaviour on the receiving end. I'm not sure if I would extend/modify xep71 for that use-case. If I had the requirement I would probably first try to mark the String and assign a semantic to the marked String by using an extra extension element: message… bodyHi Joe Bloggs. How are you?/body mark mention jid='j...@example.com' by-string string='Joe Bloggs'/ /mention /mark /message This has a few advantages: - It doesn't mess with xep71 - It also works with clients who do not support xep71, i.e. just 'body' elements. - It splits the marking and the assign semantic to mark in two different tasks The last point basically means that the features of this extension could be diverse. While I'm not sure if it's really a good idea to use it for for anything and everything, it's good to have the option: For example message… bodyWelsh looks like this: TI'n gallu ysgrifennu Cymraeg, ydy./body mark audio url='http://soundsoftheworld.com/welsh.mp3' by-range start='23' end='56'/ /mention /mark /message - Florian
