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

[Harald Tveit Alvestrand]

--On 13. juni 2007 13:29 -0700 Kenneth Whistler <kenw at sybase.com> wrote:

> Patrik Fältström wrote:
>
>> I have got privately many many comments on all algorithmic
>> specifications posted (including mine, and yours Mark). I have also
>> got many suggested algorithmic specifications privately. I think I
>> have around 10 different ways of describing what we want to do --
>> calculate the value of the derived property value.
>
> 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.

> 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.

                          Harald