[Council] VOTE[JEP-22]: -1
stpeter at jabber.org
Sat Apr 20 12:55:26 CDT 2002
Hmm, and actually the examples of cancelling a composing event are
inconsistent (Example 3 vs. Example 8), and Example 9 contains an error.
I'll fix these minor problems. I agree that the cancellation of the
composing event is rather implicit. Any suggestions on fixing it?
As to your main point, it would be cleaner, I think, if the ID were an
attribute and not an element (that would be consistent with our usage
throughout the Jabber protocols). Maybe we would have the following
<event name='offline' id=''/>
<event name='delivered' id=''/>
<event name='displayed' id=''/>
<event name='composing' id=''/>
<event name='cancelled' id=''/> // or 'stopped'?
I think "cancelled" might be ambiguous (I could see someone thinking that
delivery of the message was cancelled), but I can live with that, though I
might prefer something like "stopped".
email+jabber: stpeter at jabber.org
On Sat, 20 Apr 2002, Dave Smith wrote:
> Ok...a few questions...
> I like the overall concept. I would like to know why "events" are encoded in
> the element name. It would be much more flexible to have something like:
> <x xmlns='jabber:x:event'>
> <event name='delivered' id='M_22'/>
> That would allow for new (non-IM) event types to be added without requiring
> schema changes.
> I'm also a bit hesitant about having cancellation of events be so implicit.
> However, that's not what's incurring the -1 vote; I just want a good
> explanation of why it's desirable to hard-code event names into element
> Council mailing list
> Council at jabber.org
More information about the Council