Subject: [Lager] Fwd: Re: Where I'm at with the -01 draft

From: Asmus Freytag <[email-masked]>
Date: Wed, 26 Aug 2015 18:04:54 -0700

All,

Apparently Kim, was sitting on some edits as well, while also absent
sooner than predicted, so we now have some duplicates to sort out until 
we can post the draft.

In the meantime, here is a summary of how the way I tried to fix the 
various issues that are in the tracker (most of which we discussed 
already in the meeting).

I've done another round of spell and grammar checking on the draft as 
well, and picked up and corrected some minor issues, not separately 
called out.

A./

       #3 - Clarify domain element as it pertains to Root
   		Kim: How is the root zone represented?
   			Already text in next draft

       =>         "A type of "domain" means that the scope is a domain
		that represents
                 the apex of the DNS zone to which the LGR is applied.
                 The value must be a valid domain name, and in the
		case of the DNS
                 root zone, should be represented as "."."

       #4 - Review syntax of actions
   		Wil: Likes "allocatable" and "blocked"
   		Asmus, Yoshiro: Ditto
   		Kim: Will change in next draft

   	=>	changed "block" to "blocked" and "allocate" to
		"allocatable" where
   		these words represent recommended disposition values.

       #5 - Add text about potential effects of recursive rules
   		Asmus: The draft does not intend to allow recursive
		definitions need to make sure that the wording does
		not allow that
   		Paul: Add wording that say recursive is not allowed
   		Asmus: OK with adding such wording
   		Kim: Does this limit parser implementations?
   		Asmus: Probably not
   		Wil: His implementation parses entire XML, so it might
		be susceptible to recursion
   		Asmus: Can be a corollary or a restatement
   		Asmus will provide text for this issue

   	=>	"It is an error to  reference a rule or class for which
		 the  complete definition has not been
                 seen. In other words, it is explicitly not possible to
		define recursive rules or
   		class definitions. "

   	#8 - Just a typo

   	=>	typo in relaxNG schema, NOT FIXED YET

   	#9 - Fix domain/scope usage
   		Kim: Update all the examples

          =>	fixed

          #10 - Minor, will be fixed

   	=>	fixed
   	
   	#11 - Rule on when/not-when attributes
   		Asmus will write language to fix this

   	=> 	major refactoring of the relevant sections, new section
		 "Conditional Contexts"
		where most of the generic info is collected. Existing
		section "Conditional Variants"
		now focuses only on how these relate to variants. (too
		 big to quote here)

   	#12 - Error, will be fixed

   	=>    fixed

   	#13 - 2 syntax for ranges
   		Asmus: Was noted that there were too many uses of the
		<char> element
                  because the attributes vary
   		Rules are regular expressions, and char class can be
		done in a similar way
   			Thus not using char class for this
   		Kim: Should we be more explicit about why we chose this?
   		Asmus will add a note that says a char class is not a
		pseudo-repertoire, and will flesh this out more
   	
   	=>	"In a class definition, ranges are..." and
   		"The contents of a class differ from a repertoire in
		that the latter may
   	        contain sequences as elements, while the former may
		 not. Instead, they closely
   		resemble character classes as found in regular
		expressions."

   	#14 - Typographical error, remove some spaces

   	=>	fixed

   	#15 - Clarify when/not-when use on char/range
   		Asmus: This seems like a duplicate of #11
   			Focuses on range, strongly connected
   		Asmus will fix with same clarification as #11
   	
   	=>	see #11

   	#16	clarify actions (not discussed in meeting)
   	
   	=>	fixed by restating how actions are triggered
		Pretty much as requested in the ticket, but I
		made separate bullet items for all
		the attributes, that makes the description
		easier to read. (too much text to quote here)

   	New issue, not yet in tracker, from Asmus
   		If there are a forward and reverse context, and
		authors like to conflate these
   		This makes writing a tool that makes sure that an
		LGR is symmetric and transitive
   		Suggests to add text: don't use this type of
		shorthand, it makes it hard on us
   		This was triggered by Arabic LGR
   		Asmus has proposed language, and will write into
		the next draft

   	=> new text in draft (along the lines I described in
		the meeting, too big to quote here).

   	Marc: When the -01 is out, authors should update the
		tracker items
   	=> will do

	#17	typos
		
	=>	fixed

---

From: Audric Schiltknecht <[email-masked]>
Date: Thu, 27 Aug 2015 10:15:22 -0400

>           Asmus will fix with same clarification as #11

I had issues with webex and my mic when we were reviewing this, and
forgot to speak about it afterwards.

While this is indeed connected to issue #11, my concern is that there is
no clear text which indicates that _both_ "char" and "range" may have
"when"/"not-when" attributes whereas we have very specific sections
regarding references, comments, etc. (at least to my feeling: I had to
go back and forth between several sections and examples of the draft to
be sure of what was intended).

My proposal was to add few sentences focused on this (slightly updated
from what I put in the ticket) :

Remove the following paragraph from 4.2.5

   As described in Section 4.1 a "when" or "not-when" attribute may also
   be specified to any "char" element in the data section to define
   required or prohibited contextual conditions under which a code point
   is valid.

and create a new "Contextual Conditions" section between current 4.1
Sequences and 4.2 Variants with the proposed text:

   Contextual conditions may be defined using "when" or "not-when"
   attributes on "char" and "range" elements. These define the
   conditions under which a code point is valid. The value of the
   "when" and "not-when" attributes is a context rule as described
   below in Section 5.4. A "when" attribute specifies a rule that must
   match for the code point to be valid whereas a "not-when" attribute
   specifies a rule that must not match. As mentioned in Section 4.1,
   contextual conditions can be a more flexible alternative to
   sequences.

Audric

---

From: Asmus Freytag <[email-masked]>
Date: Thu, 27 Aug 2015 13:36:11 -0700

> be sure of what was intended).
This should be addressed by the new language
> Sequences and 4.2 Variants with the proposed text:

I took your suggestion of a new section but I worded it all a bit 
differently in the details,
and made other edits. I think you will find that the new text is now 
much clearer and
explicit.
>     contextual conditions can be a more flexible alternative to
Here's the new section in its entirety:

4.2. Conditional Contexts

A conditional context is specified by a rule that must be satisfied (or 
alternatively, must not be satisfied) for a code point in a given label, 
often at a particular location in a label.

To specify a conditional context a "when" or "not-when" attribute may be 
used. The value of each "when" or    "not-when" attributes is a whole 
label or parameterized context rule as described below in Section 5.3. 
The content condition is met when the rule specified in the "when" 
attribute is matched. Alternatively, a "not-when" attribute may be used 
for a rule that must not be matched. It is an error to reference a rule 
that is not actually defined in the "rules" element.

A parameterized context rule    (see Section 5.4) defines the context 
immediately surrounding a given code point; unlike a sequence, the 
context is not limited to a specific fixed code point, but for example 
may be a code point that is a member of a certain subset or has a 
certain Unicode property.

Given a suitable definition of a parameterized context rule named 
"follows-virama" this example specifies that a ZERO-WIDTH JOINER 
(U+200D) is restricted to immediately follow any of several code points 
classified as virama:

     <char cp="200D" when="follows-virama" />

For a complete example, see Appendix Appendix A.

In contrast, a whole label rule (see Section 5.3) specifies a condition 
to be met by the entire label, for example that it must contain at least 
one code point from a given script anywhere in the label. In the 
following example no digit from either range must occur in a label that 
mixes digits from both ranges:

     <data>
        <range first-cp="0660" last-cp="0669" not-when="mixed-digits"
               tag="arabic-indic-digits" />
        <range first-cp="06F0" last-cp="06F9" not-when="mixed-digits"
               tag="extended-arabic-indic-digits" />
     </data>

(See Section 5.3.9 for an example of the "mixed-digits" rule.)

The "when" or "not-when" attributes are mutually exclusive. They may be 
applied to both "char" and "range" elements in the "data" element, as 
well as to "var" elements (see Section 4.3.5).

If a contextual condition is not satisfied for any code point in a 
label, the label is invalid, see Section 6.5. For variants, the 
conditional context restricts the definition of the variant to the case 
where the condition is met. Outside the specified context, a variant is 
not defined .