Re: [Standards] Marking up messages with metadata and XEP-0071

[Florian Schmaus]

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:
> 
> 
>   Hi Joe Bloggs. How are you? Oh, and you Joe Bloggs too?
>   
> 
>   
> 
> 
>   
> 
>   
> 

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] DRAFT: XEP-0319 (Last User Interaction in Presence)

[Christian Schudt]

Hi,

while implementing this, I’ve recognized a few issues:

1. It should link to XEP-0012 and clarify it’s correlation to "4. Online User 
Query“. I guess if a client queries an idle client via XEP-0012 it should yield 
the same result (in seconds) as the idle time broadcast via XEP-0319, no? So 
clients should have only one source of "idle time", which is then used by 
XEP-0012, XEP-0256 and XEP-0319. Maybe it should be described in an 
„Implementation Notes“ section.

2. XEP-0256 should be updated (Appendix A): „superseded by XEP-0319“. Or will 
it become deprecated or what happens with it?

3. XML Schema is missing.

4. „Determing Support“ is missing. I am not sure, if it’s necessary at all 
(because there’s no real interaction), but most other XEP’s have this.


— Christian


Am 02.04.2015 um 22:33 schrieb XMPP Extensions Editor :

> Version 1.0 of XEP-0319 (Last User Interaction in Presence) has been released.
> 
> Abstract: This specification defines a way to communicate time of last user 
> interaction with her system using XMPP presence notifications.
> 
> Changelog: Per a vote of the XMPP Council, advanced specification from 
> Experimental to Draft. (XEP editor (mam))
> 
> Diff: http://xmpp.org/extensions/diff/api/xep/0319/diff/0.2/vs/1.0
> 
> URL: http://xmpp.org/extensions/xep-0319.html
> 

Re: [Standards] Marking up messages with metadata and XEP-0071

[Ben Langfeld]

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:


  Hi Joe Bloggs. How are you? Oh, and you Joe Bloggs too?
  

  


  

  


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  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
> > 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.
>
> 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:
>
> 
>   Hi Joe Bloggs. How are you?
>   
> 
>   
> 
>   
> 
>
> 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
>
> 
>   Welsh looks like this: TI'n gallu ysgrifennu Cymraeg, ydy./body>
>   
> 
>   
> 
>   
> 
>
> - Florian
>
>

Re: [Standards] Marking up messages with metadata and XEP-0071

[Florian Schmaus]

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
> 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.

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:


  Hi Joe Bloggs. How are you?
  

  

  


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


  Welsh looks like this: TI'n gallu ysgrifennu Cymraeg, ydy./body>
  

  

  


- Florian



signature.asc
Description: OpenPGP digital signature

[Standards] Fwd: [Council] Minutes 2015-04-08

[Kevin Smith]

FYI

> Begin forwarded message:
> 
> From: Kevin Smith
> Date: 9 April 2015 09:59:54 BST
> Subject: [Council] Minutes 2015-04-08
> 
> Logs: http://logs.xmpp.org/council/2015-04-08/
> 
> 1) Roll call
> Kev, Dave, Fippo, Lance present. Matt sends apologies.
> 
> 2) GSoC
> 
> Kev requested that any Council members who were going to give feedback on 
> proposals does so imminently, and thanked those who already had.
> 
> 3) Date of next meeting
> 
> 2015-04-29 15:00Z (Note this is three weeks away)
> 
> 4) Any other business
> 
> None
> 
> Fini

Re: [Standards] Marking up messages with metadata and XEP-0071

[Kevin Smith]

On 9 Apr 2015, at 09:24, Dave Cridland  wrote:
> Adding a (private) disco feature and checking for it in caps would be better. 
> Then, by all means, add custom attributes and markup.

+1

/K

Re: [Standards] Marking up messages with metadata and XEP-0071

[Dave Cridland]

On 9 April 2015 at 08:27, Kevin Smith  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

[Kevin Smith]

On 9 Apr 2015, at 05: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 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  tag to have the following attributes: id, 
> class, name, and style. We could misappropriate these attributes and do 
> something like John Smith. 
> 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