Subject: RE: [Ltru] 3 - Simplified registry ABNF (was: Open points before -02)

From: "Addison Phillips" <[email-masked]>
Date: Mon, 2 May 2005 12:07:47 -0700

I don't like this for a number of reasons.

1. I used the registry format definition over in the section on the extensions registry. This is only possible if there is a generic registry ABNF.

2. It is useful to actually describe record-jar formally. Perhaps an I-D should be created that does just that so that no one else need replicate this experience.

3. I don't care very much for ultra complicated ABNF which is amply handled by the text.

4. I don't think this actually makes writing a registry parser any easier (the tasks are the same)

5. It makes the registry itself somewhat uglier (whitespace use is somewhat more constrained). One thing I liked about the old registry format that I miss is that it was more eminently human readable. Anything that reduces the ability of humans to use the thing I'm not wild about.

But most of this is just my personal predilection and not a technical objection to doing this. I'll follow consensus on this.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Frank Ellermann
> Sent: 2005?5?2? 11:44
> To: [email-masked]
> Subject: [Ltru] 3 - Simplified registry ABNF (was: Open points before -02)
> 
> Here's the updated registry ABNF for:
> 
> | 3 - improve registry ABNF, simplify the corresponding chapter
> 
>   registry    = file-date *( "%%" CRLF record )
>   file-date   = "File-Date:" 1*SP date CRLF     ; first line
>   record      = 1*( field CRLF )
>   field       = type / tag / timestamp / reference / explanation
>   type        = "Type:" 1*SP ( subtag-type / "grandfathered" )
>   subtag-type = "language" / "extlang" / "script"
>               / "region" / "variant"
>   tag         = ( "Subtag:" / "Tag:" ) 1*SP tagtext
>   reference   = ( "Canonical:" / "Suppress-Script:"
>                 / "Recommended-Prefix:" ) 1*SP value
>   explanation = ( "Description:" / "Comments:" ) 1*SP text
>   timestamp   = ( "Added:" / "Deprecated:" ) 1*SP date
>   date        = 4DIGIT "-" 2DIGIT "-" 2DIGIT    ; see RfC 3339
>   value       = 1*( ALPHA / DIGIT / "-" )       ; note no WSP
>   text        = *( ASC-char / LWSP )            ; note folding WSP
>   ASC-char    = %x21-25 / %x27-7E / UNI-char    ; AMPERSAND is %x26
>   UNI-char    = "&#x" 2*6HEXDIG ";"
> 
> I've removed "Redundant:" and tagtype.  This ABNF is a subset of
> the general ABNF in draft -01, and it simplifies the implementation
> of "registry parsers":
> 
> - Five sets of fields, line folding 'LWSP' is only possible in the
>   'text' of an 'explanation' (i.e. "Comments:" or "Description:").
> 
> - A Recommended-Prefix with more than 50 characters is impossible,
>   it has no SP for the folding.  Removing 14 "Recommended-" would
>   allow 64 characters for a monster "Prefix:", and it would reduce
>   the size of the registry.  BTW, the draft -01 prefix limit is 71.
> 
> - UNI-char is only possible in the 'text' of an 'explanation', six
>   cases of a 'type' are enumerated, 'date' and 'value' have their
>   own syntax without special characters.
> 
> - No more space 'SP' before the colon, at least one 'SP' after the
>   colon, i.e. colon added to the 11 field names.
> 
> - The 11 possible field names are more visible than in draft -01.
>   The ABNF reflects Doug's latest draft registry (2005-04-30).
> 
>                            Bye, Frank
> 
> 
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 02 May 2005 22:22:20 +0200

Addison Phillips wrote:

> I used the registry format definition over in the section
> on the extensions registry.

Oops, these are additional registries _also_ in record-jar
format.  And they are available online at no cost, in the
public domain or with a IETF-compatible royalty free license.

Quite a lot of details, not only a registered singleton plus
an URL with a list of extension tags in any form defined by
their own RfC.

> It is useful to actually describe record-jar formally.

Yes.  And your syntax allows e.g. the colon in a fixed column:

Type               : variant
Recommended-Prefix : en-PN

I'm a bit confused by the *SP after the colon.  How about LWSP
after the colon, if and only if you want to allow folding after
the colon (resulting in a max. prefix length 71 instead of 51).

I would NOT like this.  But at the moment it's hard to see that
folding directly after the colon is at least utter dubious for
a field body with a date or a tag.  Is it really illegal ?

Where the field body can start with LWSP it's allowed, but is
this the case for a type, date, or tag value ?

> Perhaps an I-D should be created that does just that so that
> no one else need replicate this experience.

But IMHO not as separate LTRU I-D referenced by the main I-D.
If somebody loves the record-jat format he can copy its ABNF.

> I don't care very much for ultra complicated ABNF which is
> amply handled by the text.

I don't care for verbose explanations if the same idea can be
expressed in a single line of syntax.  Probably a matter of
taste.  But it starts to get ugly if editors say A in ABNF and
then add barricades of MUST and SHOULD very close to a "not A".

No, you haven't done this, I've seen it elsewhere.

> I don't think this actually makes writing a registry parser
> any easier (the tasks are the same)

I've used the "ignore folding" trick to parse the last draft
registry based on the idea of "field types" date, value, type,
or text.

> It makes the registry itself somewhat uglier (whitespace use
> is somewhat more constrained).

It's just the format created by Doug, I don't see where that's
ugly.  There's some unnecessary redundancy, even if you want to
keep the ABNF as is you could join all Type and (Sub)tag:

Type: whatever \  Whatever: value
Subtag: value  /

In theory you'd lose the info Tag vs. Subtag.  In practice it's
still obvious, anything without a hyphen is a subtag.  At the
moment you have 11 (or 12) field names, and 6 (or 7) types.  If
you join them you'd get 14 (or 15) field names.  That was an
idea in the "-01 nits".

> Anything that reduces the ability of humans to use the thing
> I'm not wild about.

Same here, but some features of the draft registry are not yet
documented in the ABNF.  My quick and dirty parser shamelessly
used the meta-info Type before (Sub)tag before the rest.

                        Bye, Frank