Let me rephrase my first paragraph, since it's likely to be confusing.<br><br>I differ from Ken in this respect. I think having the method used to derive the property be described in the document is fine.<br>[That is, I don't think that the current description nor the result is fine, but having a very explicit, justified description in this document is good, since it lets us judge whether the methodology is valid or not.]
<br><br><div><span class="gmail_quote">On 6/13/07, <b class="gmail_sendername">Mark Davis</b> <<a href="mailto:mark.davis@icu-project.org">mark.davis@icu-project.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I differ from Ken in this respect. I think having the method used to derive the property in the document is fine.<br><br>In fact, I think that one of the major failings of the document is precisely the reverse. For each rule that restricts characters that were allowed in IDNA2003, it should have a compelling justification, *with examples* of why such a restriction must be made. If a compelling case with examples cannot be provided, it casts clear doubt on the rationale for having the rule.
<br><br>Mark<div><span class="e" id="q_113271976d3a7ab3_1"><br><br><div><span class="gmail_quote">On 6/13/07, <b class="gmail_sendername">Harald Tveit Alvestrand</b> <<a href="mailto:harald@alvestrand.no" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
harald@alvestrand.no</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>--On 13. juni 2007 13:29 -0700 Kenneth Whistler <<a href="mailto:kenw@sybase.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">kenw@sybase.com</a>> wrote:<br><br>> Patrik Fältström wrote:
<br>><br>>> I have got privately many many comments on all algorithmic
<br>>> specifications posted (including mine, and yours Mark). I have also<br>>> got many suggested algorithmic specifications privately. I think I<br>>> have around 10 different ways of describing what we want to do --
<br>>> calculate the value of the derived property value.<br>><br>> Well, I think this is one of the key issues with the document.<br>><br>> This *should* be a data specification, not an algorithmic specification.
<br>><br>> It defines a table with data values in it.<br>><br>> For clarity, it should do so by specifying a series of criteria<br>> for inclusion or exclusion in that table, and values specified<br>> in that table. And then it should describe the data specification
<br>> in terms of set logic.<br>><br>> Mark's contribution shows how much cleaner, clearer, and *correct*<br>> such a specification is.<br>><br>> Trying to turn this into an algorithmic specification is -- in
<br>> my opinion, of course -- just wrong.<br><br>Ken,<br><br>I can't tell the difference between an algorithm specified in terms of<br>selection criteria and an algorithm specified in terms of set operations.<br>
<br>
Either they achieve the same result, or they don't.<br><br>> But...<br>><br>> The details of the algorithm to generate the table<br>> itself are *completely* uninteresting. There is no<br>> reason whatsoever why the data
<br>> specification for the table needs to be specifying algorithms<br>> for the generation of the table, because nobody outside this<br>> room, so to speak, needs to *re*implement such an algorithm<br>> in code somewhere. The data is simply there in a table, for
<br>> use by *other* algorithms that we *do* need to specify --<br>> namely the ones that determine whether a given Unicode<br>> string is or is not a valid U-label and does or does not<br>> match a particular DNS entry.
<br><br>That's a basic difference in approach that the two of us have disagreed on<br>before.<br>If you specify the algorithm, and allow discussion of the algorithm, new<br>data can be evaluated according to the algorithm, or it can be shown that
<br>the algorithm is incomplete, which may lead to a reevaluation of data<br>generated erroneously earlier (which is a problem for stability, of course.<br>You don't get something for nothing.)<br><br>The tables, unsupported by the algorithm that generated them, have no way
<br>in which people can distinguish a systematic application of rational rules<br>from "we just felt like picking this value" - an accusation that the UTC is<br>far more familiar with than it wants to be, I think.
<br><br> Harald<br><br><br>_______________________________________________<br>Idna-update mailing list<br><a href="mailto:Idna-update@alvestrand.no" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
Idna-update@alvestrand.no</a><br><a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://www.alvestrand.no/mailman/listinfo/idna-update</a><br></blockquote></div><br><br clear="all"><br></span></div>-- <br><span class="sg">Mark
</span></blockquote></div><br><br clear="all"><br>-- <br>Mark