On Thu, Mar 3, 2011 at 6:17 PM, Peter Saint-Andre <[email protected]>wrote:
> Those are good questions, but I'm out of time for further discussion > until (probably) Tuesday. I'll let other folks on the list reply. Hello Peter, if you have any comments on my original email last week, I'd appreciate some feedback. Also Peter/Kevin/et cetra, there's been some debate on the terminology I should be using in the spec. I recall that Kevin kind of liked "Edit Transforms" or terminology related to "Transform" codes. I am still in the midst of rewriting some terminology into something easier, and am aiming to more than halve the size of the spec (50%+ reduction in size) for non-boilerplate text. I am coming to a decision crossroads about the usage of "Edit Code" terminology, since it's important to make the standard "make sense" to the largest number of people. >From Section 3.8 of old spec http://www.marky.com/realjabber/realtimetext.html#protocol-editcodes it is observed that the XML edit codes during real time text are all actually "operation" codes, caused by user operations, all with visible or potentially visible effects, not necessarily just editing anymore, because they are essentially broken down to roughly these code categories: - Insert/Append text (string operation) - Delete/Backspace text (string operation) - Movement of cursor (UI operation) - A delay code, between operations (UI operation), used for inter-key delays - Future or private codes such as beep indicator / flash operation (UI operation), similiar to Control-G (BEL character) used for ICQ in the past. Operation codes can be split into two tiers, as Kevin perhaps suggested. Tier1 (basic support) would only consist of the string operations, while Tier2 (extended support) also include the UI operations. The codes are essentially a markup language that is played back in serial/sequential order. So theoretically it could be "Real Time Text Editing & UI Operations Markup Language" -- but that is excessively convoluted! Some example various candidates of naming terminology I've come up, include: *Edit Code* *Edit Markup* -- advantage: Very short phrase, self-explanatory for the _primary_ reason of operation codes -- disadvantage: Not all codes are edit codes, will need to explain that. *Operation Code* *Operation Markup* -- advantage: Short phrase is "Operation Code", more generic, and is a catch-all term. -- disadvantage: Not as self-explanatory, unless I also frequently say "Edit Operation Codes" and "UI Operation Codes" which are also still relatively nice terminology. *Control Code* *Edit Control Code* *etc.* -- advantage: Resemblance to traditional use of control codes -- disadvantage: Potentially dangerously confused with traditional control codes, makes little sense to newer programmers not accustomed to the concept of control codes Generally, I don't like "Edit Transforms" because not all codes transform the text, and for this specific XML-based format of edit codes, I don't like the use of any form of "Control Code" terminology because it can be confused with original 1-character control codes (Unicode control codes) especially since I may still have to briefly mention that control codes are not allowed except for linefeeds. Opinions? Thanks, Mark Rejhon
