Re: [Lager] AD review of draft-ietf-lager-specification-10

[Asmus Freytag <[e-mail]>]

Barry,

most of your comments are straightforward, and as far as they cover my 
contributions to the text, I'll be happy to make the required tweaks. A 
few were worthy of some comment, in some cases asking whether a proposed 
fix would seem sufficient to you.

On 3/13/2016 7:57 AM, Barry Leiba wrote:
> -- Section 6.2.5 --
> Am I the only one who doesn't understand the distinction between
> "difference" and "symmetric difference"?  I had assumed that
> "difference" contained all those in one or the other, but not both...
> but that seems to be what "symmetric difference" is (you say it's
> xor).  Please explain (to me and in the document).


I have no opinion on whether you are the only one, but the term 
"symmetric-difference" defines what you think of as "difference", while 
the latter term means simply "subtract all the elements of one of the 
sets from their union" (normally you'd expect to see "from the other 
set", but that leaves unspecified how to subtract something that's not 
in a set to begin with).

As these terms can be looked up in Wikipedia, with beautiful Venn 
diagrams, I'm not sure that we should spend time on defining them further.

However, perhaps a simple "(subtraction)" after "difference" will put 
the reader on the right track?

> -- Section 6.3.9 --
> I'm confused here, so maybe you can help me understand:
> It seems to me that in this example, the ranges are defined in terms
> of the "mixed-digits" rule, and that the rule is defined in terms of
> the ranges.  How does such a self-referential thing work?


My guess is that you are thinking the "when" attribute "defines" a range 
in some absolute way.

That is not the case. A when attribute relates to whether a label 
containing a code point from the range will be invalid.

If you think of a range like a procedure declaration, then this 
declaration exists and is independent of the nature of the "when" 
attribute. However, when you evaluate the procedure, the result could be 
a no-op (if the context defined in the when attribute is not met).
(Not-when attributes just use an inverse sense of matching, but 
otherwise there is no difference).

The presence of the when attribute does not affect the association of 
tags to code points, which is part of the declaration.

Hence, the later definition of the context rule ("no-mix..") can refer 
to the tag values without being self-referential.

You are correct, that context rule names are used before the rules are 
declared.

Looking at the text: I think section 5.3.9 is really an example of a 
context rule. So we should move it past 5.4, which covers the context 
rule explicitly for section 5. The text of Section 5.4 could be tweaked 
very slightly to make clear(er) that "action" and "disposition" refer to 
labels that contain a code point with a context rule.

Section 5.3.9 would become new section 5.4.1 and retitled "Example of a 
context rule..."

While we are touching this, mention should be made that rules (without 
anchors) could be used both as context rules and as ordinary rules - in 
principle even in the same LGR; I'm thinking that mention could come in 
either 5.4 or the new 5.4.2 as part of the edits needed to reflect the 
new flow.

> -- Section 8.5 --
>
>     Because of symmetry and transitivity, all variant mappings form
>     disjoint sets in which each of them is a variant of all other
>     members.
>
> I can't sort this one out.  "Each of them" appears to refer to each
> set, and I don't know how a set can be a variant of a member.  But if
> I instead assume that "each of them" is meant to refer to "all variant
> mappings", then I don't understand what the sets have to do with
> anything.  I'm also not following how the disjoint sets are formed in
> the first place.  Can you explain/clarify?


Good catch. Intended was:

    "Because of symmetry and transitivity, all variant mappings form
    disjoint sets. In each of these
    sets, the source and target of each mapping are also variants of the
    sources and targets of all the other mappings. "

The use of "and" is deliberate, otherwise you could get a chain, instead 
of an n (n-1) set of crosswise and reciprocal mappings.

By using "source" and "target" I also avoid having to use "code point or 
sequence".

If I make that change, would it fix your problem, or do we need to touch 
more of the discussion in that section?

> -- Section 4.2 --
>
> A minor question: Why are you making the order significant?  Why is
> that important?


This is perhaps not (entirely) editorial.

There is one strong order dependency in the Schema, which is that 
<action> elements are evaluated in order.
There are several weak order dependencies in the schema that are 
necessary to prevent recursive definitions.
Named rules and classes must be defined before being referenced via 
by-ref, but within that constraint they can be reordered.

There are additional order dependencies that simplify validation 
(logical validation, not schema validation).
Rules referenced in actions (via "match") must be defined; the Unicode 
version must be defined before creating classes based on properties 
(which are version dependent). In a few places, additional 
define-before-use constraints might have been nice but could not be 
implemented. You found the one affecting when rules.

Allowing a more "random" ordering of elements would have been possible, 
but there seems to be no use case for it. Conversely, I'm convinced that 
there's a cost in usability. LGR files that stick to a somewhat 
conventional order can also be processed by general tools, for example, 
to view differences, and not just by special-purpose software.

> -- Section 7 and subsections --
> This was a real slog to get through, and I'm quite sure I didn't
> follow a lot of it.  I have to take your word that people who are
> actually doing this stuff can follow it and get it right, including
> all the variant stuff, including the reflexive variants and the
> any-variant vs only-variants vs everything else.  I just can't imagine
> needing to do anything complicated with this and actually getting it
> right.  (This is just a comment; there's nothing actionable here.)


The complications are very necessary but (primarily) relevant to CJK 
tables, where the full scheme has been in use for a while. It is 
difficult and in fact probably the hardest part of the spec. Took me 
forever to get it all sorted out. :)

> -- Appendix A --
>
>     In practice, any LGR that includes the hyphen might also contain
>     rules invalidating any labels beginning, ending, and containing a
>     hyphen in the third and fourth positions as required by [RFC5891].
>
> Mm, then why didn't you put those in the example?  It seems to me that
> getting the rules right is the hard part, and that using real-world
> examples when you can would be helpful.

I now have access to a worked example of this from a different project, so I may just stick it in.

A./