Review of draft-philips-langtags-03: ABNF errors
Harald Tveit Alvestrand
harald at alvestrand.no
Thu Jun 24 01:01:12 CEST 2004
--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
>>
>
>
More information about the Ietf-languages
mailing list