Subject: [Lager] [lager] #40 (specification): Empty rule not specified

From: "lager issue tracker" <[email-masked]>
Date: Mon, 22 Feb 2016 20:24:25 -0000

#40: Empty rule not specified

 The draft and RelaxNG schema do not prevent creating an "empty" rule, e.g.
 {{{
 <rule name="empty"/>
 }}}
 What should be the behavior of such a rule? Or should we prevent this?

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-lager-
  [email-masked]         |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  specification            |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/40>
lager <https://tools.ietf.org/lager/>

---

From: "lager issue tracker" <[email-masked]>
Date: Mon, 22 Feb 2016 22:03:31 -0000

Comment (by [email-masked]):

 The <rule> construct is (largely) intended to capture a (slightly
 extended) form of regular expression. In fact, several implementations now
 simply map rules and classes to regular expressions for evaluation.

 In that context, a <rule> corresponds to a "group", that is "(...)".

 What about an empty rule?

 An unnamed <rule /> would be equivalent to an empty group "()" in a
 regular expression. It doesn't match anything, and it shouldn't prevent
 matches across it. So it should just be ignored.

 (I just verified that regex engines do not flag empty groups and if found
 inside a longer expression, just ignore them).

 A named empty rule can be used by reference in another rule. When
 substituted in, it expands to "nothing", so ignoring it would again be
 correct.

 If used as a trigger for an action, I suggest, it should work like an
 empty regular expression and match nothing. An action with an empty rule
 would never get triggered. It's the opposite of a catch all.

 So, that means the behavior or an empty rule is entirely regular, which
 means that there isn't a strong need to account for it.

 That said, if I wrote a tool to edit LGRs, or a tool to review them (like
 "lint") I would flag an empty rule so it could be removed. Just the same
 way that I would flag a character class that doesn't intersect with the
 repertoire (and therefore is effectively "empty"), or one where set
 operators create the empty set.

 But neither of those latter conditions are catered to by the spec or the
 schema. Regex implementations do flag an empty set "[]", but if I read
 this correctly, our production for the code-point-set-shorthand does not
 allow empty explicit sets.

 Severity:  -                        |  Resolution:
 Keywords:                           |

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/40#comment:1>
lager <https://tools.ietf.org/lager/>

---

From: "lager issue tracker" <[email-masked]>
Date: Mon, 22 Feb 2016 22:06:24 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => wontfix

Comment:

 I've set this to "won't fix". If, after reviewing, you feel there's need
 for some note/comment in the spec, please reopen.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-lager-
  [email-masked]         |  [email-masked]
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  specification            |     Version:
 Severity:  -                        |  Resolution:  wontfix
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/40#comment:2>
lager <https://tools.ietf.org/lager/>