tables document [Re: IDNA comments]

[Patrik Fältström]

On 14 jul 2008, at 20.57, Kenneth Whistler wrote:

>>>  3. "It should be suitable for newer revisions of Unicode, as long
>>> as the
>>>  Unicode properties on which it is based remain stable."
>>>  Replace by
>>>  "This is suitable for any newer versions of Unicod as well.
>                                                  ^^^^^^
> Typo in Mark's input that made it into table-02.txt.

Fixed

>> Thanks. I will though probably in the last sentence not say "...will
>> be..." but instead "...can be..." as my view is that at the point in
>> time where such an unfortunate incompatibility is detected, this
>> document has to be updated. At that update one can choose to either
>> add the codepoint to 2.2.3 or not (in reality, choose to add to 2.2.3
>> and update the document or not update the document but accept the
>> incompatibility).
>>
>> Ok with people?
>
> And yes, I'm fine with that suggestion, too.

Ok.

>>>  7. "In many cases aliases are used in the data in the Unicode
>>> Standard.
>>>  This document uses both the alias and the spelled out terms (for
>>> example
>>>  alias Ll for the General Category Lowercase_Letter)."
>>>  Replace with:
>>>  "Unicode property names and property value names may have short
>>>  abbreviations, such as gc for the General_Category property, and
>>> Ll for the
>>>  Lowercase_Letter property value of that property."
>>
>> Is it only property names and property values that have short forms?
>
> In general, yes. What Mark is referring to are the short forms
> specified in PropertyAliases.txt (for property names) and
> PropertyValueAliases.txt (for property value names).

Ok.

>>>  8. Sort the following by value instead of code point, for clarity.
>>>  Ideally each value would be in its own subsection: PVALID,
>>> CONTEXTO,...
>>>
>>>     002D; CONTEXTO  # HYPHEN-MINUS
>>>     ...
>>>     3007; PVALID    # IDEOGRAPHIC NUMBER ZERO
>>>     303B; CONTEXTO  # VERTICAL IDEOGRAPHIC ITERATION MARK
>>>     30FB; CONTEXTO  # KATAKANA MIDDLE DOT
>>
>> Hmm...what do people think here? I can see reasons to have the
>> codepoints (in the same script) "close" to each other (as it is now),
>> while still of course understand this suggestion.
>
> I agree that the list isn't long enough to bother reorganizing
> it by category here.

Ok.

>> Should also the appendix be sorted in a different way (add an  
>> Appendix
>> B in addition to existing Appendix A)?
>
> No. The least contentious (and least voluminous) way forward is
> just to leave the Appendix A as it is.

Ok.

>>>  13. "If needed, IANA should (with the help of an appointed expert)
>>>  suggest updates of this RFC where BackwardCompatible (Section
>>> 2.2.3) is
>>>  updated, a set that is at
>>>  release of this document is empty."
>>>  This isn't going to work. I suggest that the backwards compatible
>>>  character list, the exceptions list, and the context rules all be
>>> in a
>>>  single document published by IANA, and controlled by the group
>>> discussed in
>>>  rationale.
>>
>> Ok.
>
> I don't see that Mark's concern has actually been addressed
> yet on this point (Section 5. IANA Considerations). Rather
> than IANA suggesting updates to the RFC, it seems to me
> that it would be cleaner if the RFC specified that the
> BackwardCompatible list was maintained by IANA along with
> its listing of the derived property for each version
> of Unicode. The need to add anything to the BackwardCompatible
> list will be apparent when the derivation is attempted for
> each new version, if anything were to change that required
> its invocation. It is much quicker and cleaner if that
> exception list were then generated and maintained by
> the same process involved in generating the derived property
> list(s), rather than requiring kicking off a document
> revision process to get the RFC updated.

This is an action point (P5).

> After all, isn't one of the main points here to construct
> the RFC so that it doesn't have to be updated with future
> revisions of Unicode?

Yes.

What people seems to like is the non-normative list in the draft, and  
ask that to be updated when Unicode releases new versions. And the  
question is how/who/when is doing this.

I will have new text in -03 that I hope helps.

> P.S. In general, I'm quite pleased with the progress this
> document has made. I find it much simpler and clearer
> now.

Thanks!

    Patrik