Hi Martin, >> https://github.com/core-wg/core-problem-details/pull/41 > > This also looks mostly okay. Thank you. > By chance, I just noticed that you have > keyword: CoAP, API, Problem Details > Would it be possible to add any keywords related to language tagging and/or bidi? Good point! The RFC editor would have stubbed our noses on this, but good to do that now. Added “CBOR Tag”, “Language Tag”, and “Bidi”. > This explanation helps in that it confirms that overall, there are three different values and one case of no value, resulting in four different choices. So we are in agreement about the 'facts'. (originally, it wasn't clear to me whether null and absent were two different choices, or one and the same). > > What we don't yet agree is how this is presented. You want to present it as three values and one separate case/choice of an absent value. Yes, because choosing a value is very different from supplying one or not supplying one. > Thinking from the perspective of a user, I'd strongly prefer it if all four choices were listed in one single list (or table, or whatever). That way, it's immediately clear what the choices are, each with its meaning. For a user, the exact way of how a choice gets expressed (by a value, or by the absence of a value) is in my view secondary, and shouldn't be made the top-level branching point for the presentation of these four choices. But the choice is only between the three values, as the presence/absense ultimately leads to one of the three values by inheritance. >> Base-rtl and base-lang are specified to apply to unadorned (non-tag-38) strings. >> It is not defined in the current text whether an implementation would apply base-rtl to tag-38 strings with absent directionality. > > I think it's bad practice to leave things like this open. The only result it can produce is confusion, and nobody benefits from that. Why not just say that base-rtl and base-lang apply if language or direction are missing on a tag-38? Because tag 38 operates independent from the enclosing problem-details document. It needs to be possible to implement tag 38 in its own library. If that happens to have a way to supply default parameters, these could be taken from base-rtl/-lang in the calling problem-details implementation. […] >>> >>> We should make sure that the text of the RFC to be encourages 3), not 1) or 2). >> To me, (3) is really “follow the flow”, which is just a short way of saying “the reader is advised to consult ongoing standardization activities”. > > There are no ongoing standardization activities on the bidi algorithm. If you say that a string of text is in RTL (or LTR) isolation, or in first strong isolation, what that means is defined by Unicode Standard Annex #9, which doesn't "flow" at all. Indeed, that’s why we now reference Annex #9 in all three places. However, the reference to FSI is weaker, as this is just one “auto” algorithm, and the document leaves handling “auto” more open than “ltr” and “rtl” (which are now quite sharp based on your help). […] > But what's much more important here is that the solution is NOT to go read STRING-META, because STRING-META won't help. STRING-META shows different ways of how one could indicate directionality in different cases. You already made your choice, so STRING-META is no longer relevant. What counts is the Unicode Bidirectional Algorithm. > >> We left in a weaker reference (Readers interested in further details […] may want to consult […]) to STRING-META as that is still useful background material for further reading. > > This is still misleading, because readers of your document don't have much of a reason to read that document. The main reason may be to answer questions such as "why do we need such a directionality indicator", but if that's the case, your text should be more specific. OK, I took out the “for further reading” paragraph. As an implementer, I’d probably have benefitted from some background material that explains enough so it can take me off the knee-jerk “what the heck is this” reaction. But for people who already know a bit about this space, too much information may indeed be confusing. > >>> […] >>> >>>> Hence the informative reference. >>>>> […] >>>>> I'm not really sure yet about the 'absent' and 'null' entries, neither if they are really distinct nor whether the specification is good enough (we might want to specify FIRST STRONG ISOLATE semantics). >>>> We could, but I’m not sure that part of “auto” semantics is as stable as the rest. >>> >>> In TR #9, the auto semantics is as stable as the others. FSI (first strong isolate) was introduced in Unicode 6.3 together with the other isolates. And the "first strong" rule was already present from the start of the Bidi Algorithm and continues to be there until today for the overall paragraph direction (see https://www.unicode.org/reports/tr9/#P2). That also means that you get exactly these semantics if you just put every Tag 38 text on its own line (paragraph) e.g. in Win notepad. That also means that the average user of an RTL script is familiar with this behavior and what to do if it doesn't do the right thing. >> FSI is now explicitly mentioned as a choice that an internationalization library could take. > > This is progress. But the text currently says (copied directly from github): > - `null` indicates that that no indication is made about the direction > ("auto"), enabling an internationalization library to make a > decision such as treating the string as if enclosed in FSI ... PDI > or equivalent, see {{-bidi}}. > This is still too vague. What about > - `null`: Indicates auto-detection of direction. > The text is expected to be displayed with the base direction > determined by the directionality of the first strong character > if standalone, and isolated with first strong detection > (as if enclosed in FSI ... PDI or equivalent, see {{-bidi}}) > in the context of a longer string or text. I don’t think we want to make FSI the prescribed meaning of the third branch here, so I wouldn’t want to make this change. I do like the term “auto-detection” though... All the changes from this round in https://github.com/core-wg/core-problem-details/pull/42 — I’m expecting this to be the last round. Grüße, Carsten -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
