From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu May 10 2001 - 21:30:28 EDT
Please do not reply to the pwg-announce DL. Reply to ipp@pwg.org and/or
imaging@forum.upnp.org.
Its clear from the reactions to the set of requirements and the 6 issues
that was our proposed agenda, that we really need a decision tree agenda
instead. This mail message replaces the previous agenda for the telecon.
I've down-loaded the agenda/decision tree:
ftp://ftp.pwg.org/pub/pwg/media-sizes/media-size-decision-tree-010510.pdf
ftp://ftp.pwg.org/pub/pwg/media-sizes/media-size-decision-tree-010510.doc
I've also copied the agenda/decision tree into this mail message as plain
text, so you can read it either way:
Monday, May 14, 1-2 PM PDT (4-5 PM EST)
Phone: (415) 228-4883, passcode: 74584#
(Xerox folks: 8*534-6413) [confirmation code: 5954723]
Definition of the term "Field"
For purposes of this discussion, the term "Field" means a part of the Media
Size Self Describing Name, that is separated by a special character, namely
"_", which is easily scanned for and cannot occur except as a field
separator.
Agreed Requirements
The boiled down requirements (thanks, Bill), that we think we can all agree
to are:
1. Intent is program to program communication of media names. It is
not intended for use as internal representation within a program.
2. Names are to contain size information so that Recipient Software
(Client or Printer) that receives an unrecognized name can still determine
the intended size. Constraints and limitations include cut sheet only,
definition of only English and Metric dimensional units, restrict the names
to use the
characters for IPP keywords
3. Although primarily intended for machine readability, Names
should have some relation to common names. Also, Names should be structured
to present some useful information if presented directly to a user when the
names are not recognized by the machine, which includes both the name of the
media size and its dimensions.
10. Be able to register additional Media Names, including new
Class field/Naming authorities, after the standard is approved.
12, 13 Design the syntax to facilitate parsing by Recipient (Client
and Printer) Software
However, the following detailed design decision issues need to be resolved.
We are trying to decide between one or a combination of the following
syntactic methods:
a. original UPnP/HTML way (but with _ field separator): iso-a4_210x297mm,
na-letter_8.5x11in
b. Maui (D03-D07) way: iso-a4.2100-2970, na-letter.8500-11000
c. Portland decision: iso_a4_210-297, na_letter_8.5-11
d. All 1000ths of mm: iso-a4.210000-297000, na-letter.215900-279400
e. Units as a separate third field: iso-a4_210-297_mm, na-letter_8.5-11_in
Decision Tree
>From the unanimous decision on the May 2 telecon for method a and the email
push back since then, we are only considering combinations of methods a, c,
and e. The decision tree has several branches, depending on the answers
that we agree to:
1. Should there be a separate Class Field (separated by
underscore from the Media Name field) which must always be present and which
is used to indicate the naming authority, standards body, country,
geographic region, or application area? So far we have the following
classes: na, iso, jis, jpn, prc, roc, om (for other metric), oe (for other
english). Examples:
YES: iso_a4_210..., na_letter_8.5... goto 3
NO: iso-a4_210..., na-letter_8.5... goto 2
2. (not separate class field, the class information is part of
the Name Field separated by a hyphen): Does the class part of the Name
Field have to be present? If it does, then we need to invent some
miscellaneous class part, such as "oe" for other english and "om" for other
metric. If we don't, then we just omit the class part when we can't think
of a good class part. Examples:
YES: om-folio_210...or eu-folio_210 goto 4
NO: folio_210... goto 4
3. (Separate Class Field): Can the Class Field contain a
hyphen? Examples:
YES: vend-lexmark_neat-size_7...
custom-lexmark_neat-size_7
x-lexmark_neat-size_7... goto 4
NO: lexmark_neat-size_7...
custom_lexmark-neat-size_7... goto 4
4. Do non-standard names invented by *users* have to be
syntactically distinguishable with a "custom" Class Field in order to submit
to Printers that have been configured to indicate that they support custom
sizes? Examples:
YES: custom_new-size_7... goto 5
NO: new-size_7... goto 5
5. Do non-standard names invented by *system administrators*
which they use to configure their Printer supported capabilities have to be
syntactically distinguishable with a "custom" Class Field? Examples:
YES: custom_new-size_7... goto 6
NO: new-size_7... goto 6
6. Do printer vendors need non-standard sizes that aren't
registered (or do they simply register their size names as new standardized
size names)?
YES: goto 7
NO: goto 8
7. (Vendor names must appear) For non-standard sizes invented
by Printer vendors that aren't registered does the vendor's name have to
appear somewhere in the media name? Examples:
a. In Class: lexmark_neat-size_7... goto 8
b. In Class: vend-lexmark_neat-size_7... goto 8
c. In Class: custom-lexmark_neat-size_7... goto 8
d. In Name: na_lexmark-neat-size_7... goto 8
e. neither: na_neat-size_7... goto 8
8. Do we want to limit the units to mm and in forever in
standardized names?
Yes: goto 9
No: goto 9
9. Do the units have to appear explicitly in the Dimensions
Field (or does the Class Field imply the units)? If we choose the NO case,
we have to answer: what happens when new Class Field names are registered.
Examples:
YES: iso_a4_210x297mm, na_letter_8.5x11in goto 10
NO: iso-a4_210x297, na-letter_8.5x11 goto 11
10. (explicit dimensions): Should the character that separates
the smaller from the larger dimension be "x" or "-"?
"x": iso_a4_210x297mm, na_letter_8.5x11in goto 12
"-": iso_a4_210-297mm, na_letter_8.5-11in goto 12
11. (implicit dimensions): Should the character that separates
the smaller from the larger dimension be "x" or "-"?
"x": iso_a4_210x297, na_letter_8.5x11 goto 12
"-": iso_a4_210-297, na_letter_8.5-11 goto 12
12. Should the standard say anything about what the Recipient
Software does if it detects that the Media Class and Media Name combination
don't match the Dimensions Field? Choices are MUST/SHOULD/MAY for:
a. Its outside the scope of the standard
b. Its implementation-dependent
c. Use the Media Class and Media Name combination as the
intended size
d. Use the Dimensions Field as the intended size
e. Reject/ignore/substitute the name, since it is in error
This archive was generated by hypermail 2.1.4 : Thu Apr 16 2009 - 10:55:40 EDT