Here are the rest of my comments on the PWG Semantic Model in version 0.06,
dated June 17, 2002,
2. (continued) Here are some more arguments in support of using the term
"Document", instead of "Content":
In the late 1960, there was a fad in system design to invent entirely new
terms so that no one could possibly be mis-led into thinking that a term
carried along some assumptions from some other usage. However, the result
was that no one really understood anyone else, since learning an entirely
new vocabulary was much too hard. Bernie Galler from the University of
Michigan wrote a letter to the Communications of the ACM, strongly urging
system designers to abandon this fad of inventing new terms. Instead, he
said use the terms that have a common understanding. Put an adjective in
front if you really want to distinguish your term from the common usage.
Live with the term including the adjective for a while and see if you still
really need the adjective. If you don't, drop the adjective. Either way,
be sure to put the term into a terminology section and describe the
specifics of the use of the term in your specification.
So if the reason for changing the word from "Document" (which all print
standards have used) to "Content" is to avoid some kind of unwarranted
assumptions or confusions about "Document", just define what is meant by
"Document" in the PWG Semantic Model. A Document can be any electronic form
of representation that is represented by a MIME Media type, including a text
document, an XML representation, an image, etc. If you want to distinguish
between the electronic form that is submitted in a print job from the
hardcopy form that the Printer produces, you could add adjectives in front
of Document. For example, Input Document and Output Document, respectively,
as has been done for the Document and Page Overrides specification for IPP.
[Comments 1, initial 2, and 3 are below in the earlier email message.]
4. Page 5, section 1, Model Overview, the third sentence, says: "The PWG
model describes the device as a Printer object." We also need to clarify, as
in RFC 2911, that the communication can be between a desktop and a spooler,
a desktop and a printing device, or between a spooler and a printing device.
One fix would be to replace the third sentence with something like:
The PWG Model represents the entity that accepts print requests as a Printer
object. The Printer object can represent a printing device, a spooler, or
both. Such a spooler may control one or more devices and spools jobs before
forwarding them to one of the printing device.
5. Page 5, bottom of the page. Add the terms "Printer", "Client",
"Document" to the list of terms. I suggest capitalizing the first letter
when the special term is intended.
6. Page 8, section 2.1.3 "Job Processing" Printer Attributes:
I agree that the term "Job Processing" attributes is probably a better term
than the IPP Semantic Model "Job Template" attributes term, so this is an OK
terminology change (but needs to be added to the IPP mapping appendix).
7. Page 8, Table 1, JobPriority, the "xxxSupported syntax:
Change "Integer (MAX value)" to "Integer (number of priority levels)".
8. Page 14, Table 2, Sides:
Delete the two last values: 'two-sided-long-edge' [duplicate] and 'tumble'
9. Page 15, Table 2, Media:
The reference should be to [RFC2911] "media" appendix, not pwg5101.1. The
example should be something like: 'na-letter-white that is defined in RFC
2911. The next two attributes (MediaSize and MediaType) correctly refer to
10. Page 25-26, section 3.2.1 PrintJob and PrintUri, could be eliminated and
then add a note that some protocols may combine CreateJob and SendDocument
into a single operation, called PrintJob and combine CreateJob and SendUri
into a single operation, called PrintUri. This will reduce the number of
actions in the document (while still covering both IPP and PSI which do have
the combined action).
11. Page 31, Appendix - IPP Mapping
Change the title of this appendix, so that it is just specifying more detail
for the actions as part of the Model. This appendix could eliminate 7.2.1
PrintJob and 7.2.2 PrintUri. Move the details of 7.2.1 PrintJob into 7.2.3
12. Add a separate (much shorter) appendix that indicates the IPP Mapping to
the Model. Either in this Appendix also indicate the PSI Mapping to the PWG
Model, or in a separate Appendix. The advantage of having in the same
appendix, is that it will be easier to compare the IPP Semantic Model and
the PSI semantics. For example, a single table might contain three columns:
PWG Model, IPP Semantics, and PSI Semantics.
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Thursday, June 20, 2002 16:37
To: Zehler, Peter; 'BERKEMA,ALAN C (HP-Roseville,ex1)'
Cc: ps at pwg.org; pwg at pwg.org
Subject: PWG> Comments on the PWG Semantic Model document version 0.06,
dated J une 17, 2002
Here are my comments on the document. Unfortunately, I won't be able to be
at either the PSI or the PWG meeting to discuss. Have a good meeting.
1. The WG should consider whether the 10-page summary of the attributes in
section 2.3 (pages 14 through 23) should be moved back to the appendix where
the summary of the actions is. Then section 2 will be reduced from 18 pages
to 9 pages (pages 6-14) on the Data Class attributes. The figures in
section 2 give the names of the attributes and how they are grouped which
gives the reader a good overview of the attribute and object part of the
model. With such a move, section 3 Actions and 4 status codes combined will
be roughly the same size at 6 pages (pages 24-29) as section 2 (9 pages).
This was Melinda Grant's suggestion which was put into version 0.2, 5/23/02.
2. The use of the term "Content" instead of "Document" in attribute and
object names seems a step backwards and will lead to confusion with the
existing standards that have already incorporated IPP semantics into them,
such as IPP, UPnPv1, Bluetooth, and the OMG Print Facility, and the
implementations of these standards. Also ISO DPA used the term Document.
The PWG will look silly progressing a Semantic Model that covers a lot of
existing and future practice, if we change the commonly used terminology.
If the reason for the change is to allow other types of electronic
representation to be submitted in a print job, such as fonts, forms, logos,
etc., we can add a "DocumentType" attribute which indicates the type as:
'printable', 'font', 'form', 'logo', etc. This is what ISO DPA did.
3. Page 9, section 2.2, Page 12, section 2.2.2 Figure 8, and page 15,
section 2.3.2 Job Attribute:
The Job attributes that a client supplies the values for should not be
grouped with the Job attributes that the Printer alone sets. The latter
could be called Job Description attributes, as in IPP and the former called
just Job Attributes.
More comments later.
From: Zehler, Peter [mailto:PZehler at crt.xerox.com]
Sent: Monday, June 17, 2002 11:29
To: 'BERKEMA,ALAN C (HP-Roseville,ex1)'; ps at pwg.org; pwg at pwg.org
Subject: PS> PWG semantic model document version for PWG meeting
I have uploaded the version of the PWG Semantic Model document to be used at
the PWG meeting next week. I have taken Allen's version and put back the
semantics for Actions but limited it to a high level description. Detailed
discussion of parameters remain in a section dedicated to an IPP mapping of
the print semantics. I have also done some other minor edits.
We will use the PDF version, which has line numbers, in our conversations.
The PDF version is available at
MS Word version is available at
Xerox Architecture Center
Email: PZehler at crt.xerox.com
Voice: (716) 265-8755
FAX: (716) 265-8871
US Mail: Peter Zehler
800 Phillips Rd.
Webster NY, 14580-9701
From: BERKEMA,ALAN C (HP-Roseville,ex1) [mailto:alan_berkema at hp.com]
Sent: Friday, June 14, 2002 5:31 PM
To: ps at pwg.org; pwg at pwg.org
Subject: PS> Another view of the PWG semantic model
Here is another cut at the PWG Semantic Model
It started with Peter's and attempts to provides a more
generic model with the IPP specifics in the Appendix.
It also groups the collections of attributes differently.