On Sat, Aug 18, 2012 at 2:02 AM, Gunnar Hellström <[email protected]> wrote: > While in 4.6.3, where the apparently confusing note is, it is said: > > "4.6.3 Message Reset > > A message reset is a retransmission of the sender's partially composed text. > " > > The attribute 'reset' itself should be seen as a command to clear the > contents of a real-time text so that it can be (re)built from the action > elements provided. > > Would it be clearer to try to align 4.2.2 and 4.6.3 with each other, e.g. by > changing 4.6.3 to: > > "4.6.3 Message Reset > > A message reset is an order to reset the real-time message in order to > prepare for receiving the sender's partially composed text from the > beginning of the real-time message. "
That's potentially confusing too, because: -- Message 'reset' should logically be handled identically to 'new' -- The partially composed text may not necessarily be at the beginning -- the sender might start inserting a sentence in the middle, and a message reset can still occur while a sender is typing anywhere in the middle of the message. I find this less confusing: "A message reset is a retransmission of the sender's partially composed text." (Because it does not specifically refer to the XML element itself <rtt event='reset'/> ....I should ONLY explain only in the paragraphs that talk specifically mention the <rtt event='reset'/> element) So a different modification is required, as your change also makes it confusing (to a different subset of people) Let's go to section 4.2.2 instead: event='reset' For recipients, both 'new' and 'reset' are logically identical, and differ only for implementation purposes (e.g. highlighting newly-started messages). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the <rtt/> element. If a real-time message already exists, from the same sender in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent <rtt/> elements that do not contain an event attribute. Recipients MUST be able to process 'reset' without first receiving 'new'. See Message Reset, used for Keeping Real-Time Text Synchronized and Basic Real-Time Text. Observe that I tried to explain that multiple action elements are allowed, via the phrase "and then process action elements within the <rtt/> element" Notice the plural I use; "action elements" -- the "s" at the end. I hereby propose two changes: (1) A stronger clarification in the "event=reset" paragraph in section 4.2.2: http://xmpp.org/extensions/xep-0301.html#event Change: "and then process action elements within the <rtt/> element" Into: "and then process action elements within the <rtt/> element. (Any number of any [[[Action Elements(link)]]] can be included within <rtt/>)" and (2) Change the last sentence of 4.6.3. "Message Reset" http://xmpp.org/extensions/xep-0301.html#message_reset Change: "Note: There are no restrictions on using multiple Action Elements during a message reset (e.g. typing or backspacing occurring at the end of a retransmitted message)." Into: "Note: There are no restrictions on using multiple Action Elements during a message reset (e.g. typing or backspacing occurring at the end of a retransmitted message). The event='reset' attribute is specified to be treated logically identically to event='new' (except for any presentation-related behaviours), and thus has exactly the same capability." Would these two changes be acceptable to Peter? Alternatively, would Peter prefer I merge 'new' with 'reset' since they're the same anyway? And maybe introduce a separate (fourth) attribute for distinguishing message beginnings from message being reset/continued? Thanks, Mark Rejhon
