[Ietf-calsify] Status of simplification work

[George Sexton]

Oliver Block wrote:
> Hi, 
>
> I am also new to this list.
>
> Am Donnerstag, 25. Mai 2006 15:59 schrieb George Sexton:
>   
>> The point here is simplification.
>>     
>
> Simplification for whom?
>   

I thought vendors who were producing or consuming iCal files. That's the 
point of this list isn't it?

The proposed change simplifies things because programmers can simply write;

for (int i=0; i < data.length; ) {
    stream.write(data[i++]);
    if ((i%75==0) && (i<data.length))
       stream.write("\n");
}

Research has found that the number one method of reducing the number of 
defects in a program is to reduce the number of lines in that program. 
Doing octets requires:

int iCurrentLine=0,iCharLength;
for (int i=0; i < data.length; i++) {
   iCharLength=ObscureUnicodeToByteLengthConversion(data[i]);
    if (iCurrentLine+iCharLength)>75 {
       stream.write("\n");
       iCurrentLine=0;
    }
    stream.write(data[i]);
    iCurrentLine+=iCharLength;
}

 The second version is about twice as long as the 1st version, requires 
two additional variables, and requires a function call on every 
character. Given a function length for the character to byte length 
converter of 10 lines, that makes the second version almost 3 times longer.

5 lines= simpler

20 lines=more complicated
>   
>> It will result 
>> in a portion of the spec that people either don't comply with, or that
>> they do wrong.
>>     
>
> By which reason are they doing it wrong?
>   
A lot of people don't wrap at all. Of the rest I would bet that over 90% 
who are writing multi-byte UTF-8 are wrapping at 75 characters.
> Changing a spec seems to me as the most comfortable way of not solving a 
> problem one faces.
>   
I'll ignore the implied insult that I'm actually not clever enough to 
code a correct implementation.

> The question should be: Are there good reasons for that rule? 
I too am waiting to hear the good reason. So far, the only winner is it 
makes the file easier to read in a text editor.

> Does a change to 
> 75 characters lead to anything, or does it just mislead? What would you say 
> if anybody suggests to change from 75 octets to 75 words (the linguistic 
> unit).
>   
More complexity with no advantage. An average page of English text is 
500 words. Breaking on 75 words would yield 7 lines. b This would give 
the complexity of the output code having a word counter, without the 
benefit of actually making the text viewable in an editor without 
scrolling. It also assumes that the implementer can write generic code 
for any language that will identify linguistic unit separators. Doubtful.

> Interesting discussion though.:)
>   
My mistake. I thought this list was made up of people who are interested 
in improving interoperability. It appears to be a debating society where 
members compete to prove their cleverness. So far, to sum up the responses:

An obscure function that can be used to implement an algorithm 3 times 
longer than the simpler.
A suggestion that people who want to work with characters are doing so 
in misguided attempts to handle typesetting issues.
An incorrect suggestion that it doesn't matter if you interpose a 
newline character between the bytes of a UTF-8 character.
A suggestion that my desire stems from my inability to correctly 
implement the requirement.
A pointless alternative suggestion offered up in the spirit of debate.

I'm suggesting improving interoperability by increasing the probability 
that an implementer of average skill will get this part right. Do you 
want a standard that only extremely skilled programmers will have any 
chance of delivering a correct implementation, or do you want a standard 
that most people will be able to do correctly?

I'm really, really glad that I'm not putting up any money to participate 
in this comedy.

-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/