Review of draft-philips-langtags-03: ABNF errors

[Mark Davis]

You are right; we missed that. Thanks!

Mark
__________________________________
http://www.macchiato.com
► शिष्यादिच्छेत्पराजयम् ◄

----- Original Message ----- 
From: "Harald Tveit Alvestrand" <harald at alvestrand.no>
To: "Mark Davis" <mark.davis at jtcsv.com>; <ietf-languages at iana.org>
Sent: Wed, 2004 Jun 23 16:01
Subject: Re: Review of draft-philips-langtags-03: ABNF errors


>
>
> --On 23. juni 2004 15:42 -0700 Mark Davis <mark.davis at jtcsv.com> wrote:
>
> > We are using =/ as defined in the RFC
> > (ftp://ftp.isi.edu/in-notes/rfc2234.txt)
>
> No, you're not - the spec says that the "ruleset" token has to be on the
> front of EVERY production, not just the first one.
>
>                         Harald
>
> >
> > .3  Incremental Alternatives                    Rule1 =/ Rule2
> >
> >    It is sometimes convenient to specify a list of alternatives in
> >    fragments.  That is, an initial rule may match one or more
> >    alternatives, with later rule definitions adding to the set of
> >    alternatives.  This is particularly useful for otherwise- independent
> >    specifications which derive from the same parent rule set, such as
> >    often occurs with parameter lists.  ABNF permits this incremental
> >    definition through the construct:
> >
> >         oldrule     =/ additional-alternatives
> >
> >    So that the rule set
> >
> >         ruleset     =  alt1 / alt2
> >
> >         ruleset     =/ alt3
> >
> >         ruleset     =/ alt4 / alt5
> >
> >    is the same as specifying
> >
> >         ruleset     =  alt1 / alt2 / alt3 / alt4 / alt5
> >
> > For spaces, we were using them for readability (not that ABNF is
> > particularly readable anyway), but it appears that we shouldn't:
> >
> >         For Internet
> >         specifications, there is some history of permitting linear white
> >         space (space and horizontal tab) to be freelyPand
> >         implicitlyPinterspersed around major constructs, such as
> >         delimiting special characters or atomic strings.
> >
> >         NOTE:     This specification for ABNF does not
> >                   provide for implicit specification of linear white
> >                   space.
> >
> >    Any grammar which wishes to permit linear white space around
> >    delimiters or string segments must specify it explicitly.  It is
> >    often useful to provide for such white space in "core" rules that are
> >    then used variously among higher-level rules.  The "core" rules might
> >    be formed into a lexical analyzer or simply be part of the main
> >    ruleset.
> >
> >
> > Mark
> > __________________________________
> > http://www.macchiato.com
> > ? ????????????????????? ?
> >
> > ----- Original Message -----
> > From: "Harald Tveit Alvestrand" <harald at alvestrand.no>
> > To: <ietf-languages at iana.org>
> > Sent: Wed, 2004 Jun 23 13:08
> > Subject: Review of draft-philips-langtags-03: ABNF errors
> >
> >
> >> I have at last started to seriously review this document, with a view to
> >> offering my opinion to the IESG for their perusal - I'll recuse on the
> >> processing itself.
> >>
> >> But - the ABNF is NOT ready for prime time.
> >>
> >> The authors seem to believe that =/ is a continuation symbol (it is not),
> >> and that there is a space between the number-quantifier and the rule it
> >> quantifies (there isn't).
> >>
> >> Also, "x" strings are case-insensitive, so they can't be used in ranges -
> >> hex codes have to be used.
> >>
> >> And underscores aren't allowed in rule names.
> >>
> >> Here's a grammar for the stuff that at least parses correctly:
> >> ------------------------------------------------------------
> >> langtag   = lang *("-" extlang) ["-" script] ["-" region]
> >> *("-" variant) *("-" extension) *("-" private-use)
> >>       / private-use       ; private use tag
> >>       / grandfathered     ; grandfathered registrations
> >>
> >> lang            = 2*3ALPHA                ; shortest ISO 639 code
> >> / registered-lang
> >> extlang         = 3ALPHA                  ; reserved for future use
> >> script          = 4ALPHA                  ; ISO 15924 code
> >> region          = 2ALPHA                  ; ISO 3166 code
> >> / 3DIGIT                 ; UN country number
> >> variant         =  5*15alphanum           ; registered or private use
> >> variants
> >> extension       = singleton 1*("-" (2*31alphanum)) ; extension subtag(s)
> >> private-use     = "x" 1*("-" (1*31alphanum))       ; private use
> >> subtag(s) singleton       = ALPHA      ; single letters - x has spec
> >> meaning registered-lang = 4*15ALPHA               ; registered language
> >> subtag grandfathered   = ALPHA *(alphanum / "-") ; grandfathered
> >> registration alphanum        = (ALPHA / DIGIT)          ; letters and
> >> numbers
> >>
> >>
> >>
> >> _______________________________________________
> >> Ietf-languages mailing list
> >> Ietf-languages at alvestrand.no
> >> http://www.alvestrand.no/mailman/listinfo/ietf-languages
> >>
> >
> >
>
>
>
>
>