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 : Thu May 17 2001 - 21:39:32 EDT