IPP Mail Archive: RE: IPP> RE: Revised ABNF per Monday's Pho

RE: IPP> RE: Revised ABNF per Monday's Phone Conference [parsers SHOULD handle new classes]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri May 18 2001 - 13:54:59 EDT

  • Next message: Marchetti, Michael: "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@cp10.es.xerox.com]
    Sent: Friday, May 18, 2001 2:33 AM
    To: Bergman, Ron; Herriot, Robert; McDonald, Ira
    Cc: 'ipp@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@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@hitachi-hkis.com]
    Sent: Thursday, May 17, 2001 18:43
    To: 'Hastings, Tom N'; Herriot, Robert; McDonald, Ira; Bergman, Ron
    Cc: 'ipp@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@cp10.es.xerox.com]
    Sent: Thursday, May 17, 2001 6:22 PM
    To: Herriot, Robert; McDonald, Ira; Bergman, Ron
    Cc: 'ipp@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@cp10.es.xerox.com]
    Sent: Thursday, May 17, 2001 14:36
    To: Herriot, Robert; McDonald, Ira; Bergman, Ron
    Cc: 'ipp@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@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@cp10.es.xerox.com]
    > Sent: Thursday, May 17, 2001 10:33 AM
    > To: McDonald, Ira; Bergman, Ron
    > Cc: 'ipp@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@sharplabs.com]
    > Sent: Thursday, May 17, 2001 07:25
    > To: 'Hastings, Tom N'; Bergman, Ron
    > Cc: 'ipp@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@cp10.es.xerox.com]
    > Sent: Wednesday, May 16, 2001 5:01 PM
    > To: Bergman, Ron
    > Cc: 'ipp@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@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@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@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@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@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@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
    >



    This archive was generated by hypermail 2b29 : Fri May 18 2001 - 13:56:40 EDT