I think that there is confusion between a grammar change and the addition of
some new values.
A grammar change does require a change in the parser. The addition of a new
value doesn't.
One reasonable solution is for the media name parser to treat the syntax as:
media-size-self-describing-name = class-name "_" size-name "_" short-dim "x"
long-dim units
where class-name is defined as:
class-name = lowalpha *( lowalpha | digit | "." )
This syntax is invariant for any new values of the class-name, and the
parser doesn't require look-ahead to see what the value of "units" is.
> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Friday, May 18, 2001 10:55 AM
> To: Marchetti, Michael; Ron Bergman (E-mail)
> Cc: ipp (E-mail)
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference
> [parsers SHOULD handle new classes]
>>> Mike,
>> Yes, usually a change in ABNF does mean new code in a parser (which is
> expensive as you point out). However, the design of this
> standard and its
> ABNF is that the units are redundant AND the real information (the
> dimensions) are also included, so if you write your parser
> correctly, it
> won't need to be changed even when new classes (or media names) are
> encountered or custom names (defined at a site) are encountered
> (registered).
>> Since it wasn't obvious to you what our intent was and how
> parsers could be
> written even though the ABNF changes, I've copied the entire
> list and have
> some suggestions for the standard:
>> Lets consider the client parser separately from the Printer parser:
>> There are several degrees of client which display something
> to the user for
> selection and MAY format documents (where it would need to know the
> dimensions):
>> a. non-formatting client: it just treats the string as a unit
> and displays
> it to the user as is; no parsing ever. It might or might not
> localize the
> entire string. If it localizes and gets a string that it
> doesn't recognize,
> then it just displays the entire string as is (or perhaps
> breaks it up into
> separate pieces separated by a space). Such a client also
> doesn't format
> documents, so it doesn't even care about the dimensions, only
> the user and
> Printer do.
>> b. client does formatting: separates the class field, the
> name field, and
> the dimension field. It displays the class and name fields as is (or
> localizes) and converts the dimensions to the units the user
> prefers. If it
> gets a class or name field it doesn't recognize, it just
> displays it as is,
> perhaps separated by a space. It also converts the dimensions to its
> internal units for formatting documents.
>> On the Printer side, there are two cases, one that doesn't
> support client's
> inventing custom sizes and one that does. If the Printer
> displays media
> sizes to an operator or on an op panel, then that parser code
> has the same
> problems as the client (see above).
>> a. doesn't support client-defined custom sizes: the parser
> doesn't even need
> to parse the string at all; it just compares the entire
> string with a list
> of supported strings, including system administrator defined
> custom sizes.
> If there isn't a match, the Printer doesn't support that
> requested size and
> takes appropriate action.
>> b. supports client-invented custom sizes that the client sends to the
> Printer: The Printer parser has to parse the class field looking for
> "custom", then parse the dimensions and check for in range
> and convert to
> the Printer's internal units whatever they are.
>>> Ron,
>> Perhaps we need a simple note to implementers who normally
> think that ABNF
> is baked into code, such as Mike. How about:
>> Note: Although the ABNF does contain explicit class names, it is
> straightforward to write a parser that is able to handle unrecognized
> class-name and media-name fields.
>> Or alternatively, make a recommendation:
>> Although the ABNF does contain explicit class names,
> implementers SHOULD
> write parsers that are able to handle unrecognized class-name
> and media-name
> fields, as new class names and media names are registered.
>>> I also wonder if we need an Appendix with implementer hints
> like the above
> for client and printers. They are all obvious to us who have
> been working
> on this standard for the last four months, but apparently not to first
> readers.
>> Tom
>> -----Original Message-----
> From: Marchetti, Michael
> Sent: Friday, May 18, 2001 05:23
> To: Hastings, Tom N
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference [ABNF
> and the Registration procedures]
>>>> Tom,
>> I think the point you should make here is that a new ABNF
> requires a new
> parser to be written (or generated from the syntax
> description). Otherwise,
> when a new class name comes along, existing parsers will break - stop
> working in the field - not print otherwise-valid jobs - in general,
> ungracefully collapse under the weight of this changing standard. The
> parsing will fail because the name does not meet the syntax
> specification.
> To avoid this means a new code rollout to the field: flash
> upgrades, service
> engineers on site, update disks in the mail, a logistical
> nightmare so you
> can handle some new Russian paper size... isn't this standard
> supposed to be
> flexible enough to handle unrecognized sizes by parsing out the size
> information?
>> My two cents,
> Mike
>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Friday, May 18, 2001 2:33 AM
> To: Bergman, Ron; Herriot, Robert; McDonald, Ira
> Cc: 'ipp at pwg.org'
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference [ABNF
> and the Registration procedures]
>>> Ron,
>> I think we are trying to do two things with the ABNF:
>> 1. Make the ABNF show the explicit relationship of the class
> name to the
> units, rather than relying on the English statements in the document.
>> 2. Specify what the possible syntaxes are for any future
> registered class
> name, so a parser can be written today that will parse (and
> know how to
> display if necessary) all possible future class names.
>> I thought we had agreed that we didn't want to update the
> standard more than
> once a year. So any registrations would be handled like
> addenda, i.e., just
> adding new values for the tables to files in the same
> directory where the
> published standard is stored.
>> In fact, we should add a section to the standard that describes the
> registration procedure. How about something like this for a
> new section N
> (similar to IPP Model which has such a section):
>>> N Registration Procedures for Standardizing Additional Names
>> This standard will be republished as needed, but not more
> often than once a
> year. In between times, implementers can register Media Type
> Names, Media
> Color Names, and Media Size Self Describing Names to gain the
> same status as
> the standardized names in this document.
>> The proposer submits a request by email to the pwg at pwg.org> mailing list.
> The proposed name and description needs to follow the same
> patterns as the
> standardized names already present in the standard. Proposing a name
> without a description will be sent back for more information.
> The process
> is the same as for approving a PWG Draft standard (see
>ftp://ftp.pwg.org/pub/pwg/general/pwg-process.pdf), which is:
>> a. The PWG will discuss the proposal for a period of at least
> two weeks.
>> b. If there does not appear to be any further discussion and
> the proposal
> appears to have consensus, it will be sent out for a two week
> Last Call vote
> for any final comments.
>> c. Then it will be sent out for a two week vote to approve or
> disapprove
> (which can happen by email or at a PWG meeting).
>> d. After approval the approved registration descriptions will
> be added to
> the same directory where the Media Standardized Names
> standard is stored,
> using a file name of the form pwg5101.1-xxx that shows it is
> an addition to
> pwg5101.1:
>>ftp://ftp.pwg.org/pub/pwg/standards/>> Such registrations will have the same status as any name in
> the published
> standard.
>> e. Periodically, but not more frequently than once a year,
> the registered
> names will be added to a new version of the standard, the
> updated standard
> will replace the current version in the directory, and the
> registrations so
> incorporated will be removed from the directory.
>>> How does that sound?
>> We probably also need to add how to join the pwg DL in the
> Addresses of
> Authors section, like we have for the other standards.
>> Tom
>> -----Original Message-----
> From: Bergman, Ron [mailto:Ron.Bergman at hitachi-hkis.com]
> Sent: Thursday, May 17, 2001 18:43
> To: 'Hastings, Tom N'; Herriot, Robert; McDonald, Ira; Bergman, Ron
> Cc: 'ipp at pwg.org'
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference
> [synthesi s of Bob's and Monday]
>>> Tom,
>> Could you explain why simply updating the ABNF when new
> "class" is defined
> is not sufficient. This concept of "class-registered" seems
> to have leave a
> large opening that could cause problems. When a new name is
> registered that
> requires a new class, the addendum to the specification would
> contain both
> the new ABNF as well as the new name. This seems like a much cleaner
> approach. What are we trying to protect with the "class-registered"?
>> Ron
>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Thursday, May 17, 2001 6:22 PM
> To: Herriot, Robert; McDonald, Ira; Bergman, Ron
> Cc: 'ipp at pwg.org'
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference
> [synthesi s of Bob's and Monday]
>>> Here's a synthesis that keeps the ABNF specifying the class
> names that go
> with the units (as agreed at Monday's telecon), but keeps
> Bob's simpler
> productions (16) (and depends on requiring the size-name
> field to non-empty
> for custom names):
>> media-size-self-describing-name =
> class-na "_" size-name "_" short-dim "x" long-dim "in" |
> class-mm "_" size-name "_" short-dim "x" long-dim "mm"
>> class-na = "na" | "asme" | "oe" | custom-name | class-registered-na
>> class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om" |
> custom-name | class-registered-mm
>> custom-name = "custom"
>> class-registered-na = class-name
>> class-registered-mm = class-name
>> class-name = lowalpha *( lowalpha | digit | "." )
>> /* the rest of the grammar is the same as already proposed */
>> 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"
>>>>> -----Original Message-----
> From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> Sent: Thursday, May 17, 2001 14:36
> To: Herriot, Robert; McDonald, Ira; Bergman, Ron
> Cc: 'ipp at pwg.org'
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference [ABNF
> com bined into one]
>>> Bob,
>> I agree that it would be simpler if the rule about the
> media-name was the
> same for custom and standard names. I suggest that the
> media-name part be
> required (to be at least one letter or digit) in custom names, as in
> standardized names. This agrees with your ABNF.
>> Your formulation has more productions (18 vs. 15), where each
> production is
> simpler. Also your first production shows the overall syntax
> in a single
> line.
>> However, one of the agreements on Monday's telecon was to
> make the ABNF
> force the relationship between the class names and the units
> (except for
> custom). Your formulation relies on the English to do that.
>> Minor bug, the line:
> class-custome = "custom"
>> should be:
> class-custom = "custom"
>> Tom
>> -----Original Message-----
> From: Herriot, Robert
> Sent: Thursday, May 17, 2001 13:26
> To: Hastings, Tom N; McDonald, Ira; Bergman, Ron
> Cc: 'ipp at pwg.org'
> Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference [ABNF
> com bined into one]
>>> This proposed grammar is far more verbose than it needs to be.
>> For example the "media-size-self-describing-name" production could be
> simplified to
>> media-size-self-describing-name =
> ( class-na "_" size-name "_" short-dim "x" long-dim "in" ) |
> ( class-mm "_" size-name "_" short-dim "x" long-dim "mm" )
>> by defining class-na
>> class-na = class-standard-na | class-registered-na
> class-standard-na = "na" | "asme" | "oe"
>> The grammar would also be simpler (and the code simpler to
> write) if rule
> for empty "size-name" were the same for "custom" as for all
> other classes.
> That is, empty is allowed for all or none.
>> The grammar can be further simplified by using English rather
> than syntactic
> structure to show the link between class and units. I would
> simplify the
> grammar and add the following comments 'the units "in" can
> be used only
> with values of "class-na", "class-registered-na" and
> "class-custom", and the
> units "mm" can be used only with values of "class-mm",
> "class-registered-nn"
> and "class-custom"'. The new grammar would be:
>> media-size-self-describing-name =
> class "_" size-name "_" short-dim "x" long-dim units
>> class = class-na | class-mm | class-custom | class-registered-na |
> class-registered-mm
>> class-na = "na" | "asme" | "oe"
>> class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om"
>> class-custome = "custom"
>> class-registered-na = class-name
>> class-registered-mm = class-name
>> class-name = lowalpha *( lowalpha | digit | "." )
>> units = "in" | "mm"
>> /* the rest of the grammar is the same as already proposed */
>> 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"
>>> > -----Original Message-----
> > From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> > Sent: Thursday, May 17, 2001 10:33 AM
> > To: McDonald, Ira; Bergman, Ron
> > Cc: 'ipp at pwg.org'
> > Subject: RE: IPP> RE: Revised ABNF per Monday's Phone
> Conference [ABNF
> > com bined into one]
> >
> >
> > The one thing that makes custom a little different from the
> > others, is that
> > the size-name field can be empty (but the 2 "_" characters
> > must be present).
> >
> >
> > So how does this look for a combined ABNF:
> >
> > media-size-self-describing-name =
> > ( class-na "_" size-name "_" short-dim "x" long-dim "in" ) |
> > ( class-mm "_" size-name "_" short-dim "x" long-dim "mm" ) |
> > ( class-registered-na "_" size-name "_" short-dim "x"
> > long-dim "in" )
> > |
> > ( class-registered-mm "_" size-name "_" short-dim "x"
> > long-dim "mm" )
> > |
> > custom-media-size-self-describing-name
> >
> > custom-media-size-self-describing-name =
> > "custom" "_" [ size-name ] "_" short-dim "x" long-dim (
> > "in" | "mm" )
> >
> > class-na = "na" | "asme" | "oe"
> >
> > class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om"
> >
> > class-registered-na = lowalpha *( lowalpha | digit | "." )
> >
> > class-registered-mm = lowalpha *( 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"
> >
> > -----Original Message-----
> > From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
> > Sent: Thursday, May 17, 2001 07:25
> > To: 'Hastings, Tom N'; Bergman, Ron
> > Cc: 'ipp at pwg.org'
> > Subject: RE: IPP> RE: Revised ABNF per Monday's Phone Conference
> > [today's telecon s uggestion]
> >
> >
> > Hi Tom,
> >
> > I like all of this. Except that I urge (as I did yesterday) that
> > there be a FIFTH standard class 'custom' in the one single ABNF
> > production (along with class-in, class-mm, etc.). Keep the separate
> > section giving more detail on 'custom' sizes but integrate the
> > ABNF please.
> >
> > For machine parsing, we need a single ABNF for valid size names.
> >
> > Cheers,
> > - Ira McDonald
> >
> >
> > -----Original Message-----
> > From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> > Sent: Wednesday, May 16, 2001 5:01 PM
> > To: Bergman, Ron
> > Cc: 'ipp at pwg.org'
> > Subject: IPP> RE: Revised ABNF per Monday's Phone
> Conference [today's
> > telecon s uggestion]
> >
> >
> > Ron,
> >
> > Ira, Norbert, Bob, and I met today for the Media Standardized
> > Name telecon.
> >
> > Here is our suggestion for the ABNF which should meet
> > everyone's objectives:
> >
> > 1. Treat in and mm class names equally in the ABNF.
> >
> > 2. Do include the class names for both in and mm in the ABNF (as you
> > suggested).
> >
> > 3. Also include two new productions for registered in and mm
> > class names to
> > show their allowed syntaxes. Otherwise, what can be
> > registered and what can
> > Recipient code be expected to accept?
> >
> > 4. Invent more suggestive names for the four class
> > productions, than class1,
> > class2, class3, and class4. We suggest: class-in, class-mm,
> > class-registered-in, and class-registered-mm.
> >
> > 5. Allow the "." for registered class names.
> >
> > So here is the complete ABNF section that we suggest,
> > followed by the custom
> > ABNF:
> >
> >
> > 5.1 Media Size Self Describing Name Format
> > This specification defines a new Media Size Self Describing
> > Name format that
> > is recommended to be used by all new implementations. This
> > new format has
> > the Media Size Name and the Media Dimensions embedded within
> > the string and
> > allows a device to operate without a Media Size Name to Media
> > Dimensions
> > table. The Media Size Self Describing Name format is
> > structured as follows
> > using ABNF:
> >
> > media-size-self-describing-name =
> > ( class-na "_" size-name "_" short-dim "x"
> long-dim "in" ) |
> > ( class-mm "_" size-name "_" short-dim "x"
> long-dim "mm" ) |
> > ( class-registered-na "_" size-name "_" short-dim
> > "x" long-dim
> > "in" ) |
> > ( class-registered-mm "_" size-name "_" short-dim
> > "x" long-dim
> > "mm" )
> >
> > class-na = "na" | "asme" | "oe"
> >
> > class-mm = "iso" | "jis" | "jpn" | "prc" | "roc" | "om"
> >
> > class-registered-na = lowalpha *( lowalpha | digit | "." )
> >
> > class-registered-mm = lowalpha *( 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"
> >
> > 5.1.1 class-in This string part is present to indicate
> > the name space or
> > jurisdiction for the size name in order to prevent name
> > clashes for English
> > (inch) dimensions. Examples include "na" for North America,
> > "asme" for the
> > American Society of Mechanical Engineers, "oe" for other English.
> >
> > 5.1.2 class-mm This string part is present to indicate
> > the name space or
> > jurisdiction for the size name in order to prevent name
> > clashes for metric
> > (millimeter) dimensions. Examples include "iso" for the
> International
> > Standards Organization, "jis" for Japanese Information
> > Standard, "jpn" for
> > Japan, "prc" for People's Republic of China, "roc" for
> > Republic of China
> > (Taiwan), and "om" for other metric.
> >
> > 5.1.3 class-registered-in This string part is present to
> indicate a
> > registered class name that uses the English (in) dimensions.
> > See section
> > TBD for the registration procedures that define additional
> > standardized
> > names after this standard is published.
> >
> > 5.1.4 class-registered-nn This string part is present to
> indicate a
> > registered class name that uses the metric (mm) dimensions.
> > See section TBD
> > for registration procedures that define additional
> > standardized names after
> > this standard is published.
> >
> > 5.1.5 size-name This string provides a textual
> > description of the media
> > size. It is normally derived from the Legacy or Alias name
> > associated with
> > the media size. The size-name can consist of multiple parts,
> > with each part
> > separated by a hyphen (0x2D).
> >
> > 5.1.6 short-dim and long-dim These values define the
> > media size. The
> > short-dim is always the smaller of the two dimensions. The
> > dimensions are
> > presented in decimal format to as many places as necessary to
> > define the
> > size. Trailing zeros must never be used if a decimal portion
> > is present.
> >
> > 5.1.7 ( "in" | "mm" ) These values define the units of
> > measure for the
> > media size which are inches (in) and millimeters (mm). For
> > interchange
> > between programs, the dimensions are never converted to the
> > other system of
> > units, but must remain as defined in this standard. Furthermore, an
> > identical size shall never appear in this standard [I propose
> > we delete the
> > previous 3 words, since the requirement should apply wherever
> > these names
> > are interchanges - Tom] with different units. Programs may
> > convert the
> > dimensions to other units when displaying these names to
> > human users and for
> > internal use, both of which are outside the scope of this standard.
> >
> > 5.1.8 General
> > The Media Size Self Describing Name shall not contain any
> > space characters
> > (0x20).
> > Wherever possible, the Media Size Self Describing Name has
> > been derived from
> > the Legacy Name. In many cases the class portion is
> > identical to the Legacy
> > Name. In the remaining cases, the class portion must be
> > ignored to match
> > the Legacy Name.
> >
> > 5.1.6 Examples:
> > The letter size (8.5 inches by 11 inches) used in North America:
> > na_letter_8.5x11in
> > The iso A4 size (210 mm by 297 mm) used in metric countries:
> > iso_a4_210x297mm
> >
> >
> > 5.2 Custom Media Size Self Describing Name Format
> > The Custom Media Size Self Describing Name format allows
> > extensibility of
> > the media size set without an update to this specification.
> > This feature is
> > primarily intended for special media sizes that are used at a
> > minimum number
> > of locations. The Media Size Self Describing Name format for
> > custom sizes
> > is almost identical to the format for the standardized sizes:
> >
> > custom-media-size-self-describing-name =
> > "custom" "_" [ size-name ] "_" short-dim "x" long-dim (
> > "in" | "mm" )
> >
> > Refer to section 5.1 for the remaining ABNF definitions for
> the above.
> >
> > 5.2.1 Example: A custom form measuring 6 inches by 14
> > inches known as
> > "long and narrow".
> >
> > custom_long-and-narrow_6x14in or custom_ln_6x14in
> >
> > 5.2.2 The size-name "max" shall be reserved to indicate an
> > upper size
> > limit of either a device or application. Also, the size-name
> > "min" shall be
> > reserved to indicate a lower size limit. Example: For a
> > device that can
> > process forms as small as 2 x 3 inches to 18 x 36 inches:
> >
> > custom_max_18x36in and custom_min_2x3in
> >
> >
> > Comments?
> >
> > Thanks,
> > Tom
> >
> >
> > -----Original Message-----
> > From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> > Sent: Tuesday, May 15, 2001 15:54
> > To: 'Hastings, Tom N'; Bergman, Ron; Ira McDonald (E-mail);
> Don Wright
> > (E-mail)
> > Cc: 'ipp at pwg.org'
> > Subject: RE: Revised ABNF per Monday's Phone Conference
> >
> >
> > Tom,
> >
> > I known we discussed both of your issues, but I do not
> recall such an
> > agreement.
> >
> > It was my understanding that all class names need to be
> > registered as either
> > "inch class" or "mm class". This was the only way to
> guarantee their
> > uniqueness.
> >
> > And to keep the class names simple, they were to be a single word.
> >
> > What is the advantage of not adding the class to the ABNF?
> > We must always
> > update the document to add any new names, and the ABNF can be
> > updated at the
> > same time.
> >
> > Ron
> >
> > -----Original Message-----
> > From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
> > Sent: Tuesday, May 15, 2001 11:01 AM
> > To: Bergman, Ron; Ira McDonald (E-mail); Don Wright (E-mail)
> > Cc: 'ipp at pwg.org'
> > Subject: RE: Revised ABNF per Monday's Phone Conference
> >
> >
> > I believe that we agreed that the mm class names wouldn't need to be
> > explicitly listed in the ABNF, since most new class names that are
> > registered will be using the "mm" units. Then we don't have
> > to update the
> > ABNF, except in the unlikely event that a class name that
> > uses "in" units is
> > registered.
> >
> > Also we agreed that the registered class names couldn't have
> > "-" in them,
> > but could have "." (as in registry path names).
> >
> > So here is my suggested ABNF instead (which just changes the
> > class2 line):
> >
> > media-size-self-describing-name =
> > ( class1 "_" size-name "_" short-dim "x" long-dim "in" ) |
> > ( class2 "_" size-name "_" short-dim "x" long-dim "mm" )
> >
> > class1 = "na" | "asme" | "oe"
> >
> > class2 = lowalpha *( 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"
> >
> >
> > -----Original Message-----
> > From: Bergman, Ron [mailto:Ron.Bergman at Hitachi-hkis.com]
> > Sent: Tuesday, May 15, 2001 09:18
> > To: Tom Hastings (E-mail); Ira McDonald (E-mail); Don
> Wright (E-mail)
> > Cc: 'ipp at pwg.org'
> > Subject: Revised ABNF per Monday's Phone Conference
> >
> >
> > Here is my proposed ABNF to document the agreed restrictions
> > in yesterday's
> > phone call. I may be missing some of the class names but
> this should
> > correctly linl\k each class to only one set of units.
> >
> >
> > media-size-self-describing-name =
> > ( class1 "_" size-name "_" short-dim "-" long-dim "in" ) |
> > ( class2 "_" size-name "_" short-dim "-" long-dim "mm" )
> >
> > class1 = "na" | "asme" | "oe"
> >
> > class2 = "iso" | "jis" | "jpn" | "prc" | "roc" | "om"
> >
> > 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"
> >
> >
> > Any comments?
> >
> > Ron
> >
>