Tom,
I thought that the ABNF was supposed to formally describe a grammar that
defines the set of valid name strings. If that's not the case, you should
state that in the document (but in that case, why provide an ABNF grammar at
all?). Otherwise, I would recommend providing a complete ABNF, including the
syntax for future ("registered") class names.
Basically, I'm agreeing with your second requirement for the ABNF:
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.
The point I made about rolling out new code was in response to Ron's
question:
What are we trying to protect with the "class-registered"?
My answer is that we are protecting the ability to write and deploy parsers
the actually implement the ABNF in the spec.
Mike
-----Original Message-----
From: Hastings, Tom N
Sent: Friday, May 18, 2001 1:55 PM
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
>