[Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Gregg Vanderheiden gv at trace.wisc.edu
Tue Jul 24 15:31:35 UTC 2012

I agree

the word by word is often brought up -- but never implemented.  It make little sense to add this here and confuse the discussion.  You can't do word by word without XEP-0301 == and if doing XEP-0301 you can do   NT or WbWord or SbSentence or CbClause whatever you want.  But I would not get into discussing or mentioning them except to say that you can allow any of them as options in a client but should be on the receiving side as a preference.  

Talking about doing word by word but sending fragments if person is slow etc is just confusing this standard.   Keep it simple I think. 

Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   ---   http://GPII.net

On Jul 24, 2012, at 10:01 AM, Gunnar Hellström wrote:

> On 2012-07-24 01:41, Mark Rejhon wrote:
>> On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström <gunnar.hellstrom at omnitor.se> wrote:
>> On 2012-07-23 21:17, Mark Rejhon wrote:
>>> Example 1: I suggest that this could be better demonstrated by not
>>> cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or
>>> something like that. Experience and/or cynicism say that implementers
>>> are quite likely to look at the examples, ignore the text, and
>>> misunderstand what's going on if the examples provide convenient
>>> semantics not required by the protocol.
>>> [Comment]
>>> I don't like this change.  Are you sure?   
>>> In some earlier messages, I mentioned that word transmission is *greatly preferable* to broken-word transmission.
>>> Also, if an implementer misunderstands, this detail is a more harmless misunderstanding than broken-word transmission.
>>> There are other examples in the spec.
>>> Comments welcome from people other than Kevin and Gunnar -- I need more comments because I have comments that they prefer this Introduction, so I need to reconcile conflicting advice about the Introductory example.  XEP-0301 permits you to transmit real-time text any way you want: character-at-a-time, word-at-a-time, word bursts, original typing intervals, time-smoothed, etc.   The Introductory Example is unable to demonstrate all of the possible methods.  IMHO, I chose the 'safest' introductory example.
>>> Again, word transmission is greatly preferable over broken-word transmission.  (There's been arguments in some accessibility organizations in some countries, some say they prefer keypress intervals, some prefer word transmission instead of keypresses, etc.)   I am talking to a guy from a telco in UK, and he informed me of a political debate.  
>>> Can at least a few more "outsiders" comment on this change, please?  Thanks :-)
>> I have also noticed occasional theoretical discussions about word transmission instead of real-time text. But that just introduces delays. Long words can take long time to type on small devices, and many times you have benefit of seeing the word created in real-time so that you can keep your mind in sync with the sender. 
>> We discussed this before.  If a word takes longer than usual to type, you just simply transmit whatever the word is so far.  It will cause occasional broken words for those times that people take a long time to compose a word.   But that's OK. 
>> Even if it could be mentioned somewhere, the spec is about real-time text, and the first example, showing the very basic features shall also show a realistic example of transmitting real-time text. Not word-by-word.
>> I disagree. There are implementers demanding word transmission.  
>> Your edit is rejected unless there's lots of demand (i.e. 5 people publicly agreeing with you with no further disagreements in the mailing list)
>> Word-by-word also have the risk of delaying the last typed word from being transmitted. It must have some inactivity timeout and transmit whatever is typed if the user just stops typing at the end of a word without any space or punctuation mark. In order to not interfere with slow typing, a timeout should likely be in the order of 7 seconds. That is an unfortunate extra delay in these circumstances.
>> That is not a problem, if you have a time limit for word composition (i.e. 1 second transmission interval, and reset the transmission interval everytime you hit the spacebar.  So that words come out very quickly, with no delays more than 1 second)
>> Please accept the proposals for the first example being a real-time text example.
>> I need comments from several people.  There are people (some of Darren Sturman's colleagues) who would disagree with you.
>> Thank you,
>> Mark Rejhon 
> The word-by word issue is a theoretical one that has been up for discussion in the real-time text area occasionally through the years. ( especially in UK, I do not know why. ) I am not aware of any implementation or investigation that has shown that it has any benefit over Natural Typing or time smoothing. Even if you say that there is demand for word-by word, it should not be allowed to confuse the readers in the first example of a real-time text standard. 
> I propose that you follow the advice and do real-time text in the first example. 
> Please note that no explanations around example one says that it is intentionally made on word boundaries. It would be more logical to mention it in the text among implementation notes in chapter 6, and let the specification start with explaining the main implementation.
> And, in fact word-by-word is mentioned in 6.1.4. It is not under a heading that would make you find it easily. You may change the heading or divide the section in two if you want it to be more visible.
> Gunnar  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120724/41343777/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120724/41343777/attachment.bin>

More information about the Standards mailing list