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

[Barry Leiba <[e-mail]>]

Hi, Asmus, and thanks for the quick response.  I'm only leaving things
below that I think need my further response.  Summary: we're good
here.

>> 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).

Ah, I see... my confusion was in forgetting that the order of the
elements is significant, so that it's well defined.  You can probably
leave it as it is, though I'll suggest an update anyway:

OLD
   Classes may be combined using operators for set complement, union,
   intersection, difference and symmetric difference (exclusive-or).
NEW
   Classes may be combined using operators for set complement, union,
   intersection, difference (elements of the first class that are not in the
  second) and symmetric difference (elements in either class, but not
   both).
END

>> -- 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.

Yes, I was.

> That is not the case. A when attribute relates to whether a label containing
> a code point from the range will be invalid.
...
> The presence of the when attribute does not affect the association of tags
> to code points, which is part of the declaration.

OK, understood.
Your other comments about moving some text around sound right, but
you've answered my question here, and I think we're fine.

>> -- 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?

Yes, I think your suggested change works.

>> -- 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).
...
> 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.

Thanks for the explanation, and I'm quite convinced.  No change here.

Barry