The first thing wrong with the description is that you have to provide an explanation of what the proposed operational difference is between Maybe Yes and Maybe No. If you don't provide a clear explanation of why you need these two different catagories when the normal English meaning is identical, it is impossible to really assess what is going on. The relation between property values and operation has to be crystal-clear.
<br><br>Wording like<br><pre> "For each rule, it is specified whether it is a rule that increase or<br> decrease the value of the property (regarding likelihood to be<br> included in a U-label),"</pre>I find extremely fishy. It makes it sound like IDNA will only give you a *probability* that an IDN is valid, instead of saying that a particular IDN is valid or not.
<br><br><br>My take on what we meant by Always, Maybe, and Never are:<br><br><div style="margin-left: 40px;">Always: Is accepted as part of an IDN in IDNAbis, and will be accepted in all future versions (unless the IETF decides otherwise).
<br><br>Never: Is not accepted as part of an IDN in IDNAbis, and will not be accepted in any future versions (unless the IETF decides otherwise).<br><br>Maybe: Is not currently accepted as part of an IDN in IDNAbis, but may move to Always or Never in a future version (on decision of the IETF or some registrar or some other undisclosed mechanism).
</div><br>It is not at all clear how you think that Maybe No and Maybe Yes differ from Maybe, nor what is motivating this move. What is the problem you are trying to solve, and why is this the solution??<br><br>===<br><br>
Now, as far as the calculation goes. One presumes, although it is not stated, that the rules are evaluated in order, based on the suffix "<span style="font-family: monospace;">P</span>rocessing<span style="font-family: monospace;">
</span>terminates" in the first two clauses. Unfortunately, that phrase is missing from the remainder of the clauses, which makes them formally in conflict.<br><br>What I'm guessing you are trying to do based on what you have written is have something equivalent to the following, which incorporates both the rules and the calculation. I'm using sets rather than the corresponding property notation.
<br><br>Create the following sets based on the properties of each code point cp.<br><br>Grandfathered = set of all cp such that<span> <br></span><ul><li><span>cp is in [-A-Z0-9]</span></li></ul><span>
</span><span><br></span>Functional = set of all cp such that<br>
<ul><li>generalCategory(cp) is {Ll, Lu, Lo, Lm, Mn, Mc, Nd}, AND
</li><li><span>NFKC(cp) == cp</span>, AND</li><li><span>casefold(cp) == cp</span>, AND</li><li>!defaultIgnorableCodePoint(cp)</li></ul><br>Archaic = set of all cp such that<br><ul><li>script(cp) in {Xsux, Ugar, Xpeo, Goth, Ital, Cprt, Linb, Phnx,
<span name="st">Khar</span>, Phag, Glag, Shaw, Dsrt}, OR<br> </li><li>block(cp) in {Combining_Diacritical_Marks
_for_Symbols, Musical_Symbols, Ancient_Greek_Musical_Notation}</li></ul><br>Favored = set of all cp such that<br><ul><li>script(cp) in {Latn, Grek, Cyrl},</li></ul><br>Then derive the following sets:<br><ul><li>Always = Grandfathered | (Favored &
<span>Functional)</span></li><li><span>Maybe_Yes = !Favored & Functional</span><span></span>
</li><li><span>Maybe_Not = Archaic | (!Favored & !Functional)</span><span></span></li><li>Never = everything else<br></li></ul>
where | is UNION, & is INTERSECTION, ! is COMPLEMENT<br><br>The property values align with the corresponding sets.<br><br>The names for these sets are arbitrary and short. Archaic would be better phrased as "not in modern, customary use", but that's too long.
<br><br>Mark<br><br><div><span class="gmail_quote">On 6/13/07, <b class="gmail_sendername">Patrik Fältström</b> <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</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;">
On 13 jun 2007, at 03.50, Mark Davis wrote:<br><br>> But 3. "Calculation of the derived property". that section is very<br>> hard to<br>> make out. Moreover, it is impossible to assess what it is supposed
<br>> to be<br>> doing until the difference between Maybe Yes and Maybe No is<br>> completely<br>> spelled out operationally, and the goal is made clear.<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>I choose one that I feel I have most "votes" for. But I know I also<br>have people that dislike it.<br><br>Mark, if I ask you differently: Do you see anything WRONG in my way<br>of describing the calculation? As a different question than whether
<br>you feel it is hard to follow or "not the most optimal way of<br>describing what we want to do".<br><br>I must start there, to see what I can do about it in the document.<br><br> Patrik<br><br></blockquote>
</div><br><br clear="all"><br>-- <br>Mark