Glen,
We appreciate your effort. If possible I would like some comment from Google
on what would be most useful considering their current activities. But it
was my understanding that we would initially work on the identification of a
proposed element subset of the current PWG Job Ticket and Capabilities.
Thanks,
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Petrie, Glen
Sent: Thursday, February 14, 2013 10:00 AM
To: Zehler, Peter; mfd at pwg.org; cloud at pwg.org
Subject: [Cloud] RE: "Support Levels" for the SM2.0/PWG:PJT
Pete
As I said I most likely just misunderstood the request. I believe the
action item came from a discussion on what Google is currently doing with
CDD. Maybe just a simple mapping (for a binding) is what is really needed
here and I just got carried away. [At least for me, identifying the levels
was useful and perhaps beneficial to others.]
Glen
_____
From: Zehler, Peter [mailto:Peter.Zehler at xerox.com]
Sent: Thursday, February 14, 2013 6:31 AM
To: Petrie, Glen; mfd at pwg.org; cloud at pwg.org
Subject: RE: "Support Levels" for the SM2.0/PWG:PJT
Glen,
I don't know what was requested since I don't work here anymore;) But I
would think defining some sets of ticket elements applicable to various
print complexity levels would be suffice. I would preface the document with
an explanation of how unsupported/unknown elements are handled. Print
Clients and Cloud Print Systems could choose from these suggested sets and
implement them. Anything outside their implementation would be ignored.
The "MustHonor/ipp-attribute-fidelity" processing rules would still apply.
I don't see the need for an additional level of server complexity to provide
a client version specific view when mismatch handling is already
accommodated.
Pete
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Thursday, February 14, 2013 9:16 AM
To: Zehler, Peter; mfd at pwg.org; cloud at pwg.org
Subject: RE: "Support Levels" for the SM2.0/PWG:PJT
Pete,
I have pretty much the same understanding as you do; as perhaps all the
individual how are regularly involved with PWG specifications. However,
others, that is, someone new trying to create a Print Client may not have
the same understanding. So I believe my action item was to identify a few
definitive Print Client support levels. Perhaps the action item is not
needed or I have misunderstood what was requested.
Glen
_____
From: Zehler, Peter [mailto:Peter.Zehler at xerox.com]
Sent: Thursday, February 14, 2013 3:53 AM
To: Petrie, Glen; mfd at pwg.org; cloud at pwg.org
Subject: RE: "Support Levels" for the SM2.0/PWG:PJT
Glen,
The semantic model, and IPP, has never had the position of "requiring all
Applications and Print Clients in the various environments to support the
complete set of PWG: PJT objects, elements, attributes and values".
Anything a Print Client does not understand can be silently dropped on the
floor. (The model does define some mandatory elements. Those are 22
Printer Status and Description elements and 9 Job Status and Description
elements. Most of those deal with charsets, languages, state and
identifying information.) There is no requirement that Printers or Clients
must even support a PJT. If a PJT is supported only 1 element must be
supported (i.e., JobName). If a Print Document Ticket is supported then
only 2 elements must be supported (i.e., DocumentFormatSupplied and
LastDocument).
There is no requirement that "Print Client must support all PWG:PJT objects,
elements, attributes and values that any Print Service could potentially
provide as a capability". For that matter there is no requirement that the
Print Service must support all the PWG:PJT. The Client can be coded to only
understand a small subset of the model, the entire model, a superset of the
model or even a subset with extensions. When the Client encounters an
element it does not understand it silently ignores it. The end user will
only see the intersection of the set of elements supported by the Client and
those implemented by the Printer.
Then again maybe I don't understand the problem you are trying to solve.
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Petrie, Glen
Sent: Wednesday, February 13, 2013 1:29 PM
To: mfd at pwg.org; cloud at pwg.org
Subject: [Cloud] "Support Levels" for the SM2.0/PWG:PJT
All
I was asked to provide a set of (call them) support levels for the
SM2.0/PWG:PJT. I have completed the top level objects and would like feed
back on my proposal levels.
All of my documentation is done as C-Code for now. [For BJSON, JSON, XML
or whatever, as you will see later, my code contains a "def" struct for each
element/attribute/value which are used for converting internal binary
(struct) data.]
Wording for Support Levels:
The Print Job Ticket (PJT) consist of a rich set of printing objects,
attributes, elements and values that support the simplest level of printing
to most complex. It supports printing from/in embedded, mobile,
home-office, business office and production environments. However,
requiring all Applications and Print Clients in the various environments to
support the complete set of PWG: PJT objects, elements, attributes and
values would be a burden. While a Print Service only needs to provide
capability information that is supports; currently, a Print Client must
support all PWG:PJT objects, elements, attributes and values that any Print
Service could potentially provide as a capability; this is just not
practical in all situations and environments. This section provides a
solution by defining several Support Levels that a Print Client can
advertise to Print Services.
An individual Support Level consist of proper subset of the complete set of
PWG:PJT objects, elements, attributes and values. Currently, there are
three Support Levels. The first level represent "Simple" printing needs,
the second level supports nominal/typical office printing and, the third
level, represent the full PWG:PJT specification.
Any Print Client or Print Service may elect to implement (advertise and
comply to) one of the SM2.0/PWG:PJT Support Levels. When a Print Client or
Print Service declares implementation of a Support Level, the Print Client
or Print Service MUST be capable of supporting all objects, elements,
attributes and values for that Support Level. If a Print Client does not
declare a specific Support Level implementation, the Print Client SHALL have
an assumed Support Level of the most encompassing (all objects, elements,
attributes and values) Support Level.
A Print Client MAY advertise to a End-User an object, element, attribute
and/or value at a higher Support Level only if the Print Client directly
supports that object, element, attribute and/or value.
For example, a Print Client at Support Level 1 MAY advertise "Front Cover"
support (a Support Level 2 element); but, the Print Client MUST provide all
internal implementation to support a Front Cover. This is analogous to
Print Service with no Front Cover capability but with Print Client support.
A Print Service MUST NOT provide capability data or Print Job Ticket at the
Support Level above that of the Print Client. The Print Client MAY either:
i) Reject the Print Job Ticket in it entirety, or
ii) Reject the Print Job Ticket for unsupported MUST_HONOR
elements, or
iii) Ignore the unsupported object, element, attribute and/or
value.
Please review info at
ftp://ftp.pwg.org/pub/pwg/mfd/white/Proposed.PWG.PJT.Support.Level-2013.02.1
3.zip
(did not mean to put the last one in cloud directory)
glen
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
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/cloud/attachments/20130214/5f14ed60/attachment-0002.html>