Ira,
If you are correct that ABNF is routinely compiled into tailored parsers,
then the grammar has an additional problem of too much look-ahead. The
parse cannot determine whether to reduce to class-in or class-mm (at the
beginning of the production) until it reaches a "mm" or "in" at the end of
the production.
> -----Original Message-----
> From: McDonald, Ira [mailto:imcdonald@sharplabs.com]
> Sent: Thursday, July 12, 2001 6:40 PM
> To: 'don@lexmark.com'; Bergman, Ron
> Cc: 'Hastings, Tom N'; Bergman, Ron; ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> Hi folks,
>
> There's a misunderstanding of use cases going on here.
>
> ABNF is routinely compiled directly into tailored parsers.
> If the 'reg-name' production isn't there, then no LEGAL
> newly registered name which IS known to a printer can be
> used successfully by an existing client or intermediate
> proxy, because it fails the ABNF rules.
>
> This is not a hypothetical case.
>
> Cheers,
> - Ira McDonald
>
> -----Original Message-----
> From: don@lexmark.com [mailto:don@lexmark.com]
> Sent: Thursday, July 12, 2001 11:20 AM
> To: Bergman, Ron
> Cc: 'Hastings, Tom N'; Bergman, Ron; ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
>
>
> I care and I agree with Ron on this.
>
> **********************************************
> * Don Wright don@lexmark.com *
> * Chair, Printer Working Group *
> * Chair, IEEE MSC *
> * Member, IEEE SA Board of Governors *
> * Member, IEEE-ISTO Board of Directors *
> * *
> * Director, Alliances & Standards *
> * Lexmark International *
> * 740 New Circle Rd *
> * Lexington, Ky 40550 *
> * 859-825-4808 (phone) 603-963-8352 (fax) *
> **********************************************
>
>
>
>
> "Bergman, Ron" <Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com> on
> 07/11/2001 06:42:47 PM
>
> To: "'Hastings, Tom N'"
> <hastings%cp10.es.xerox.com@interlock.lexmark.com>,
> "Bergman, Ron"
> <Ron.Bergman%Hitachi-hkis.com@interlock.lexmark.com>
> cc: "ipp (E-mail)" <ipp%pwg.org@interlock.lexmark.com> (bcc: Don
> Wright/Lex/Lexmark)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size
> Self Describing
> Names
>
>
>
> Tom,
>
> As I said in my last email, I believe that separating the registration
> requirements from the media size name ABNF is cleaner. It is
> then very
> obvious that the class-xx name is restricted to the given
> names. Addition
> of reg-class-xx-name to the media size names ABNF muddies the
> water. When
> this is only in a section that describes the requirements for
> new class
> names, everything is clean. The best way to define that the
> parser must be
> able to deal with new names is with text, not the ABNF.
>
> I don't see anyone else commenting on this issue. Does that
> mean that no
> one cares?
>
> Ron
>
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> Sent: Wednesday, July 11, 2001 12:19 PM
> To: Bergman, Ron
> Cc: ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> So to be clear about the issue about how to represent the
> ABNF for future
> registered class names:
>
> (a) in the ABNF in the Media Standardized Name standard itself and
> (b) the ABNF in the flat file on the PWG server
>
> (a) For the ABNF in the standard to which sending implementations and
> receiving implementations are to conform, should the ABNF include the
> reg-class-in-name and reg-class-mm-name productions or not in
> the single
> ABNF? If the productions for the registered class names is
> removed from the
> single ABNF, then they will appear later in the document
> explaining what the
> syntax is for additional registered class names (as in the
> D0.9 draft).
>
> So should the first productions in the standard be:
>
> media-size-self-describing-name =
> ( class-in "_" size-name "_" short-dim "x" long-dim "in" ) |
> ( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
>
> class-in = "na" | "asme" | "oe" | "custom" | reg-class-in-name
> class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" |
> "custom" |
> reg-class-mm-name
>
> reg-class-in-name = ( lowalpha | digit ) *( lowalpha |
> digit | "." )
> reg-class-mm-name = ( lowalpha | digit ) *( lowalpha |
> digit | "." )
>
> or:
>
> media-size-self-describing-name =
> ( class-in "_" size-name "_" short-dim "x" long-dim "in" ) |
> ( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
>
> class-in = "na" | "asme" | "oe" | "custom"
> class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" | "custom"
>
> with a later section in the standard saying that additional
> class-in and
> class-mm names will be registered with the following syntax:
>
> class-in-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
> class-mm-name = ( lowalpha | digit ) *( lowalpha | digit | "." )
>
>
> (b) The same questions are repeated for the first ABNF that
> appears in the
> PWG server (and which also appears in the standard as the
> first snap shot).
>
> The answers to (a) and (b) don't have to be the same.
> However, it may be
> less confusing if the ABNF can be the same for:
> (1) the ABNF for conformance to the standard
> (2) the first ABNF to appear on the PWG server, and
> (3) the snap shot copy of that first ABNF to appear in the standard
> Then this ABNF can appear only once in the standard.
>
> Tom
>
>
>
>
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
> Sent: Tuesday, July 10, 2001 17:20
> To: 'Hastings, Tom N'; Bergman, Ron
> Cc: ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> Tom,
>
> But they will be in "a single production", since the ABNF
> will always be
> updated with the new registered values. I call that everyone
> agreed that
> the ABNF did not have to explicitly indicate that new values
> can be added.
>
> I like to hear from some developers that will "implement
> according to the
> ABNF" on this subject.
>
> Ron
>
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> Sent: Tuesday, July 10, 2001 5:07 PM
> To: Bergman, Ron
> Cc: ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> Ron wrote:
>
> I see you added "reg-class-xx-name" to the class-name
> definition. It seems
> like this definition is better handled as in D0.9.
> Otherwise, it could be
> interpreted to mean that arbitrary values can be added
> without registration.
> This is probably getting a little picky, but we want the ABNF to be a
> stand-alone specification.
>
>
> But if you remove the "reg-class-in-name" and "reg-class-mm-name"
> productions from the ABNF, then an implementation that
> follows the ABNF
> strictly, cannot accept a registered name that was registered
> AFTER the code
> was shipped. I think there will be objections from those who
> commented that
> all of the ABNF for conforming names should be in a single
> production, not
> in several pieces in the standard.
>
> Tom
>
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
> Sent: Tuesday, July 10, 2001 16:22
> To: 'Hastings, Tom N'; Bergman, Ron
> Cc: ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> Tom,
>
> I spoke with Norbert yesterday concerning the syntax change
> to "custom" and
> he thought it was a good change. Since he probably has the
> most complete
> implementation using the media size names, I suspect this
> will not be an
> issue with anyone else.
>
> I agree that the ABNF should be included in the specification. But it
> should be noted that it is only a snap-shot in time and
> should never be used
> for more than an example. The "real ABNF must ALWAYS be
> obtained from the
> referenced file. I am not sure what you mean by...
>
> "Another reason to include the ABNF in the standard is that
> fetching the
> current ABNF from the web site isn't required (for an
> implementation or an
> implementer)."
>
> but it seems that an implementer would always want to see the
> latest. In
> practice, I don't expect to see many updates to the ABNF, but
> it should be
> pointed out that an update is possible. (I will add text
> that provides the
> appropriate warning.)
>
> I see you added "reg-class-xx-name" to the class-name
> definition. It seems
> like this definition is better handled as in D0.9.
> Otherwise, it could be
> interpreted to mean that arbitrary values can be added
> without registration.
> This is probably getting a little picky, but we want the ABNF to be a
> stand-alone specification.
>
> Ron
>
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> Sent: Monday, July 09, 2001 2:46 PM
> To: Bergman, Ron
> Cc: ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> I should have pointed out that the name field will now be
> required for a
> custom size name, as well as standardized names, whereas in
> Draft D0.9 the
> name field was optional in custom names.
>
> There are two advantages to requiring a name field in a
> custom size name:
>
> 1. The syntax for custom and standard names becomes the same,
> simplifying
> implementation (since both will require a name).
>
> 2. It is good practice for an administrator when defining a
> custom size to
> invent some sort of a name to suggest the size's use to its users.
>
> Ron,
>
> About your second question, I see I wasn't clear about
> whether or not the
> ABNF would appear in the standard or only in the PWG FTP
> site. I think that
> the first ABNF (current with version 1.0 of the standard)
> should be in the
> standard, including the commenting, so that implementations
> can see what to
> expect in case they choose to fetch the current (updated)
> ABNF from the PWG
> site.
>
> When we post the final approved standard, we should also post
> the ABNF flat
> file which will be identical to what is in the standard. Only when we
> register a new size name that needs a new class name, will we
> need to update
> the ABNF flat file on the PWG server. Periodically, but not
> more frequently
> than, say, once a year, we will update the standard with new
> size names and
> any new class names that have been registered in the meantime.
>
> Another reason to include the ABNF in the standard is that
> fetching the
> current ABNF from the web site isn't required (for an
> implementation or an
> implementer).
>
> Tom
>
> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman@Hitachi-hkis.com]
> Sent: Monday, July 09, 2001 11:23
> To: 'Hastings, Tom N'; ipp (E-mail)
> Subject: RE: IPP> MED - Proposed final ABNF for Media Size Self
> Describing Names
>
>
> Tom,
>
> It should be pointed out that this does change the current
> syntax for custom
> size names, in that the "size-name" will be mandatory. This part is
> optional in the current draft.
>
> Also, I would like a clarification. Does this proposal
> completely remove
> the size ABNF from the document? Or, is the ABNF included with a note
> indicating where to get the latest? Although it may be
> somewhat confusing,
> it would be cleaner to only include the reference to the ABNF.
>
> Ron
>
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
> Sent: Monday, July 09, 2001 10:57 AM
> To: ipp (E-mail)
> Subject: IPP> MED - Proposed final ABNF for Media Size Self Describing
> Names
>
>
> Ron and I want to publish a final version of the Media
> Standardized Name
> standard for Last Call. There are three standards that
> require its use, so
> we need to complete the Media standard. One is UPnP Basic Printing
> Template. Another is IPP FAX.
>
> Please send any comments on this proposed ABNF BEFORE we
> publish the next
> draft. Silence will be interpreted as agreeing with the ABNF.
>
> ****************************************************************
> Please send any comments by Tuesday, July 17, 2001.
> ****************************************************************
>
> There has been the suggestion on the mailing list that the
> ABNF should be a
> single production, including the custom part and the future
> registered class
> name part as is common practice.
>
> We are also agreeing to retain the explicit list of class
> names in the ABNF.
> When a new size name is registered which needs a new class
> name, then the
> ABNF will be updated to include the new class name. The
> updated ABNF will
> be available on the PWG site as a flat text file in a
> published and stable
> URL.
>
> Advantages of this approach:
>
> 1. All of the ABNF for the Media Size Self Describing Name is
> specified as a
> single ABNF production, so that code can be written that will
> be stable,
> even as new media size names are registered with new class
> names. This is
> the common practice for other standards that use ABNF.
>
> 2. Which class names go with which units is part of the ABNF,
> so that it is
> clear that using the wrong set of units with a class name
> violates the ABNF
> and permits a parser to detect such mal-formed ABNF.
>
> 3. Using a single "custom" class name (rather than one for in
> and one for
> mm) simplifies the parsing for custom names because the
> parser needs to look
> for one special prefix ("custom"), as with Media Type and Media Color,
> rather than for, say, "custom-in" and "custom-mm" class names. Since
> administrators are defining the custom sizes, not vendors,
> whether they
> choose in or mm units will depend on their users.
>
> Disadvantages of this approach:
>
> 1. When new class names are registered, the existing parsers
> won't be able
> to validate that the units are correct, unless they access
> the PWG web site
> for the current ABNF. (The standard will NOT require
> implementations to
> access the PWG web site to get the current ABNF, nor does it
> require that
> implementations detect corrupt names that use the wrong units).
>
> The ABNF flat file will have comments at the beginning to
> identify the date
> and version of the standard and the date and version of the
> ABNF. The ABNF
> date and minor version number will be updated every time it
> is updated. The
> ABNF follows RFC 2234.
>
> Here is the proposed final ABNF as it will appear in the flat
> file on the
> PWG site in:
> ftp://ftp.pwg.org/pub/pwg/standards/pwg5101-abnf.txt:
>
> ; ABNF for the Media Size Self-Describing Name
> ; Part of the IEEE/ISTO 5101.1 Media Standardized Names standard
> ; For use with the IEEE/ISTO 5101.1 Standard Version 1.0, July 9, 2001
> ; ABNF version 1.0, July 9, 2001
> ; This ABNF is updated whenever a new media size class name
> is registered
> ; according to the procedures of IEEE/ISTO 5101.1.
>
> media-size-self-describing-name =
> ( class-in "_" size-name "_" short-dim "x" long-dim "in" ) |
> ( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
>
> class-in = "na" | "asme" | "oe" | "custom" | reg-class-in-name
> class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" |
> "custom" |
> reg-class-mm-name
>
> reg-class-in-name = ( lowalpha | digit ) *( lowalpha |
> digit | "." )
> reg-class-mm-name = ( lowalpha | digit ) *( lowalpha |
> digit | "." )
>
> size-name = ( lowalpha | digit ) *( lowalpha | digit | "-" )
>
> short-dim = dim
>
> long-dim = dim
>
> dim = integer-part [fraction-part] | "0" fraction-part
>
> integer-part = non-zero-digit *digit
>
> fraction-part = "." *digit non-zero-digit
>
> lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
> "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
> "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
>
> non-zero-digit = "1" | "2" | "3" | "4" | "5" | "6" | "7" |
> "8" | "9"
>
> digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
> "8" | "9"
>
>
>
This archive was generated by hypermail 2b29 : Fri Jul 13 2001 - 15:49:32 EDT