--On Monday, 27 June, 2022 10:56 +0200 Carsten Bormann
<cabo@xxxxxxx> wrote:
>...
>>>> Next, let me make sure that I get this right: This is a
>>>> Boolean value, but it can in effect have four different
>>>> states, yes? That would be: - True (rtl)
>>>> - False (ltr)
>>>> - null (no indication about direction, but overriding any
>>>> context) - absent (no indication about direction, but
>>>> context may apply) If that's true, then it might be good to
>>>> put that into a more structured from (something like the
>>>> above list).
>>> Thanks, see below. (A value that is absent is not a value;
>>> its representation by a null value may be needed to
>>> ~~override~~ reset any context available.)
>> In one of the patches, you collapsed my four-point list to
>> three points.
> This is really a ternary setting, with `ltr` (represented by
> false), `rtl` (by true), and `auto` (by null). The fourth case
> is that the setting is not given, i.e., absent. The default
> value for that case is taken from the context (not specified
> where that would come from) that overrides (sorry) this
> default. If there is no context, the default default is `auto`.
If you, as document author, don't know or cannot specify where
the determining context comes from, isn't omitting the keyword
and value equivalent to "do whatever you feel like, possibly
considering whatever else you can figure out"? If that is
actually the case, why not just say that? Or, as one
alternative, why not make it explicit that the keyword and value
(probably even in the "null"/auto case are optional only if the
language and script are strictly LTR?
Backing up a bit, you (and presumably the WG) concluded, even
before you sought external advice, that specifying direction is
important. Then you added these two options ("null" and omitted
entirely) to allow not specifying it. That feels to me like we
are going around in circles or, at least, shifting
responsibility for making the decisions to people who may be
much less expert on the subject than the WG (much less the WG
with help from IETF Last Call).
So, suggestions (pick one):
(1) Get rid of the two "make up your own mind" options and
require the value
(2) Spell out the circumstances under which the value MUST be
specified, indicate that it MAY be present in any of the other
cases, and then move on.
(3) If you can describe coherently what it would mean in a way
that would cover all cases, make the third value "inherited" and
make omitting the parameter exactly equivalent to it.
"Inherited" is the only way in which "from context" appears to
me to make sense. If I am missing other cases that would
dictate context, that makes spelling out when the third and
forth options are useful even more important.
Free advice: Don't do (3) unless you think it is absolutely
necessary: the odds of getting further bogged down are very high.
best,
john
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
