Line 283ish: We should tighten up the language about scope. It makes it sound like PrintDocumentProcessing elements are common and something to worry about, then backs out of that as the paragraph goes on. It would be better to start with the common case, then describe how, if specified, PrintDocumentProcessing is associated with a document and overrides the PrintJobTicket's settings.
Line 316: Is "capabilities element" actually a proper term eg "Capabilities element"?
Section 4.1: I think a super-cutdown example of an XML PrintJobTicket and PrintJobTicketCapabilities would be very valuable here. We're describing what everything is, but I think an example or two would make all the difference.
4.2: We should split this into two paragraphs. If MustHonor is specified and the printer cannot handle the request, do they fail the job?
4.3: This seems to conflict with the information in section 4.1. Isn't document scoped information overriding job scoped information? Also, the fact that we indicate that the PrintService MUST do something, then immediately say there is no guarantee seems flimsy.
Line 360: is this an implementation note? Do we want to preface this with something like "Implementers Note: ..."? Can we make it active voice?
Line 368: Can we make this active voice?
Line 371: What are container elements? This section is tough to parse.
Line 384: These don't need to be parenthetical since they're substantive to the line.
Line 386: Can we reword to "All PrintJobTicket elements are optional with the exception of the JobName element which appears in the PrintJobDescription group. "
General: Everywhere we are showing a diagram that describes the XML schema, it seems we should have more details about the datatype being specified in the text. We may be able to autogenerate much of it from the XSD, but it should add some utility to the spec as a reference, since people will be able to do things like string search against the text elements of the spec.
Line 488: Is there a scenario where someone would want to do use this in a single-document job?
Line 516: If a vendor specifies both a private descriptor and a public descriptor, what is the expected behavior if the two conflict?
Table 1: What is the condition that could cause these to be required? This isn't obvious in the table.
Table 3: The term implicit isn't specified anywhere else. As a conformance term, we should make sure people know what we mean.
From: Zehler, Peter
Sent: Tuesday, January 17, 2012 9:34 AM
To: pwg-announce at pwg.org<mailto:pwg-announce at pwg.org>
Subject: PWG Last Call of PWG Print Job Ticket and Associated Capabilities specification (1/17/12 - 2/17/12)
All,
[This PWG Last Call will start today on Tuesday January 17, 2012.
This PWG Last Call will end Friday February 17, 2012 at 10pm US PDT.]
This is the formal announcement of the PWG Last Call for the PWG
Print Job Ticket and Associated Capabilities specification, located at:
<ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-sm20-printjobticket10-20120117.pdf>
All required attributes and values defined in this document have
been prototyped by Xerox and/or other vendors through their deployment
of existing protocols such as ISO 10175, IETF/PWG IPP and WS-Print.
The MFD WG has completed a working group last call and subsequent
revisions of this document.
The PWG Process/3.0 requires that a quorum (30%) of PWG voting members
must acknowledge a PWG Last Call (with or without comments), before any
document can progress to PWG Formal Vote. This PWG Last Call is NOT a
Formal Vote but it DOES require your review acknowledgment.
Please send your review acknowledgment *exactly* as follows:
To: mfd at pwg.org <mailto:mfd at pwg.org<https://www.pwg.org/mailman/listinfo/pwg-announce>>
Subject: <Company Name> has reviewed the Print Job Ticket and Associated
Capabilities specification and has [no] comments
Please do NOT simply reply to this note on the PWG-Announce list.
Note: The PWG Definition of the Standards Development Process Version
3.0 is located at:
<http://www.pwg.org/chair/membership_docs/pwg-process30.pdf>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20120222/d4716284/attachment-0002.html>