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: Herriot, Robert (Robert.Herriot@pahv.xerox.com)
Date: Fri May 18 2001 - 16:52:41 EDT

  • Next message: Michael Sweet: "Re: IPP> Proposed deletions and additions to Media Types for Media Std"

    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@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@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 - 16:54:10 EDT