I wholly agree with Bill on this.
You want something a little more complicated than you have already specified:
{n}^({a}){m}{e} => {e} {n-1}*{m ? m-n : ''}({a} {e}) ; where n > 0
{e} *{m ? m-1 : ''}({a} {e}) ; where n == 0 or n undefined
Note the n == 0 is a special case. Note that this assumes that m > n. There seems little point in this construction if m == 1, but this does handle that case.
Aside from those sorts of problems, the definition of 'a' is a little loose. You should try to build on the RFC 5234 ABNF in your definitions.
The proposed rule has an ABNF definition something like (?):
hat-rule = 1*DIGIT "^(" a ")" 1*DIGIT
a = VCHAR / SP / HT / <any other separator>
That's a lot of flexibility in the internal part. Too much flexibility. Using parentheses means that they need to be distinguished from the parentheses that might appear in the 'a' part.
If you see this as a substitute for the "*" in a normal repetition rule, that makes it easier. Given that it has length longer than 1 character, by providing a clear delineation of the start and end you can be more flexible on the content. Either that or to restrict what follows the ^.
Preferably delineate better AND restrict content:
repeat /= hat-rule
hat-rule = *DIGIT "^" element "^" *DIGIT
This restricts the content without preventing the use of more complex content - you just have to use a rulename instead.
You can't use elements (note the 's') here because that sort of complexity is a real pain to specify.
That leaves examples:
1^";"^3element ; 1 to 3 elements separated by ;
1^SP^element ; 1 or more elements separated by SP rule
^","^3element ; 0 to 3 elements separated by ,
^%x20.20^element ; any number of elements separated by a two space characters
You should try to answer the question in the draft: why use the '^' character instead of the '#' character? I guess that this is an arbitrary choice more than anything else.
--Martin
On 2010-12-07 at 11:07:17, Bill McQuillan wrote:
> I found several problems with this draft.
>
> In overview, the reason that we removed the #rule from ABNF was that it
> was
> very difficult to specify for a general case. This draft has the same
> problem.
>
> The production given does not actually produce the desired results.
>
> > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element))
>
> If the usage is:
>
> 5^(",")10 "abc"
>
> it would allow something like:
>
> abc abc abc abc abc abc , abc
>
> not:
>
> abc, abc, abc, abc, abc, abc, abd
>
> which was probably intended.
>
> -----
>
> The production:
>
> > a = VCHAR / SP / HT / <any other separator>
>
> does not seem to address the possibility of multi-character separators
> very
> clearly. What if I want to define a list like:
>
> abc and def and ghi and jkl
>
> can I use:
>
> ^(" and ")ident
>
> -----
>
> I also do not believe that *FWS belongs in such a general rule and
> should
> rather be defined by the actual usage. E.g.:
>
> 5^(*FWS "," *FWS)10 "abc"
>
> -----
>
> Typo: 2.1 Examples, fourth example should be: ^("-")element
>
> --
> Bill McQuillan <McQuilWP@xxxxxxxxx>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf