New version, draft-faltstrom-idnabis-tables-02.txt, available

[Martin Duerst]

At 06:18 07/06/14, Harald Tveit Alvestrand wrote:
>
>
>--On 13. juni 2007 13:29 -0700 Kenneth Whistler <kenw at sybase.com> wrote:

>> Well, I think this is one of the key issues with the document.
>>
>> This *should* be a data specification, not an algorithmic specification.
>>
>> It defines a table with data values in it.
>>
>> For clarity, it should do so by specifying a series of criteria
>> for inclusion or exclusion in that table, and values specified
>> in that table. And then it should describe the data specification
>> in terms of set logic.
>>
>> Mark's contribution shows how much cleaner, clearer, and *correct*
>> such a specification is.
>>
>> Trying to turn this into an algorithmic specification is -- in
>> my opinion, of course -- just wrong.
>
>Ken,
>
>I can't tell the difference between an algorithm specified in terms of selection criteria and an algorithm specified in terms of set operations.
>
>Either they achieve the same result, or they don't.

I think what Ken is saying is that he doesn't like Section 3.
I have to agree with him that the way it's written, it's
suboptimal. The way it should be written is, as Ken said,
in terms of set operations, defining the criteria for each
category. So not: "start with ... and then ... and then these
are in category X,..." like now, but:

1) A character is in set ALWAYS iff: ...

2) A character is in set MAYBE YES iff: ...

and so on. It may be that Patrick's problem with this approach
is that it is difficult to verify that a character may not
end up in two categories (for current characters, it's easy
to check by enumeration, but for future allocations, it has
to be checked logically).


>> But...
>>
>> The details of the algorithm to generate the table
>> itself are *completely* uninteresting. There is no
>> reason whatsoever why the data
>> specification for the table needs to be specifying algorithms
>> for the generation of the table, because nobody outside this
>> room, so to speak, needs to *re*implement such an algorithm
>> in code somewhere. The data is simply there in a table, for
>> use by *other* algorithms that we *do* need to specify --
>> namely the ones that determine whether a given Unicode
>> string is or is not a valid U-label and does or does not
>> match a particular DNS entry.
>
>That's a basic difference in approach that the two of us have disagreed on before.
>If you specify the algorithm, and allow discussion of the algorithm, new data can be evaluated according to the algorithm, or it can be shown that the algorithm is incomplete, which may lead to a reevaluation of data generated erroneously earlier (which is a problem for stability, of course. You don't get something for nothing.)
>
>The tables, unsupported by the algorithm that generated them, have no way in which people can distinguish a systematic application of rational rules from "we just felt like picking this value" - an accusation that the UTC is far more familiar with than it wants to be, I think.

That is true whether you specify the generation of the tables
in terms of logic or set operations (just criteria, no sequential
operations) or in terms of a stepwise procedure.

In general, for a specification, a descriptive approach is preferred
to a procedural. Using procedural terms to specify something is
on occasion necessary, but in this case, it should not be necessary.

So I agree with Mark and Harald and others that the draft should clearly
specify the generated tables, but this should be done not by specifying
a procedure of how to generate them, but the criteria (logic/set operations)
for each category. I think that Ken also agrees that we need this
description; when he writes above that "the data is simply in the table",
I don't think he meant that we can remove everything else but the
table itself (section 4) from the draft when it's done.


Regards,   Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp