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 -------------------------------------------------------- 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.hellst...@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
smime.p7s
Description: S/MIME cryptographic signature
