Michael,
Thanks for the detailed feedback on this thread. Our developers discussed
your comments and would like to directly address them.
I'd like to introduce you to Aleksey Shlyapnikov, the author or our
Semantic Sates/Status document. Please look for an email from him that
continue this discussion.
Regards,
Kelly
kdLucas
On Sun, Mar 17, 2013 at 5:38 PM, Michael Sweet <msweet at apple.com> wrote:
> Kelly,
>> On 2013-03-06, at 10:47 PM, kdLucas <kdlucas at google.com> wrote:
>> I've attached a new specification related to Google Cloud Print 2.0:
> Google Cloud Print Semantic States, and is provided in PDF format. This new
> specification is designed to complement our Cloud Device Description
> Specification.
>> Your feedback is welcomed.
>>> Overall this looks like a pretty clean mapping of what you can get from a
> modern printer. The main issues I see are a lack of computer-readable
> messages and a very different job state implementation that will cause a
> lot of headaches for implementation.
>> My comments:
>> 1. PrinterStateSection: Doesn't have any kind of a "roll up" state
> indicating that user attention is required. Check out the IETF Printer MIB,
> IPP, and the Semantic Model for some examples of how this is done - having
> the roll-up state eliminates the need for the client to look at all of the
> state information to determine the answer...
>> 2. CloudConnectionStateType: How about a "not configured" value - I
> believe I made the same suggestion for the Privet protocol as well.
>> 3. VendorState: While I understand wanting to have a human-readable string
> here, it is equally-important to have something a computer can understand.
> Consider UI that might show an alert for a warning from the printer - "low
> ink" is something you probably want to just show and hide automatically,
> while "out of ink" is something you want to interrupt the user for and give
> them the option to cancel, restart, or continue the job. And this is
> something you likely want control over on the client side since UI choices
> may be different depending on the platform involved. Also, I would avoid
> providing an example like "System error 404." unless you want to see a lot
> of those impossible-to-decypher messages... :/
>> 4. InputTrayState: If the level is a percent, then the values should go
> from 0 to 100. Vendors are going to get this wrong with a name like
> "level_percent", so either change the range or change the name to "level",
> "level_proportion", or something other than "level_percent".
>> 5. OutputBinState: See #4.
>> 6. MarkerState: See #4. Also not clear from the document how you get a
> description or other information about the marker supply that is referenced
> - using the Marker.ID that is defined elsewhere?
>> 7. MediaPathState: See #3.
>> 8. CoverState: See #3.
>> 9. JobStateType: What state is reported if the user cancels a job?
> Also, "draft" isn't a state that is exposed in the semantic model - either
> the job is created or it isn't - there is no in-between. A job that hasn't
> been closed (received all of its documents/document URIs) is in either the
> pending (queued) or pending-held states, with a supplemental state string
> of "job-incoming", meaning that the printer/service is waiting for the
> document data/URIs to be submitted for the job. We've defined a minimal set
> of job states (pending, pending-held, processing, processing-stopped,
> aborted, canceled, completed) in order to reflect the state of the job
> object itself. The JobStateReasons element in the semantic model gives you
> additional state information about what the service is doing with the job
> object, and I encourage you to adopt a notion of "reasons" or "sub-states"
> for the current job state since it makes things much cleaner.
>> Also, your job state diagram seems to indicate that all jobs are initially
> held?!? Held jobs in the Semantic Model are an "equal" state to "pending"
> (your queued), and either can be the initial state of the job, as well as
> going from pending to pending-held or vice-versa. See the bottom of page
> 111 in RFC 2911 for an example of what we use for job states:
>>> The following figure shows the normal job state transitions.
>> +----> canceled
> /
> +----> pending --------> processing ---------+------> completed
> | ^ ^ \
> --->+ | | +----> aborted
> | v v /
> +----> pending-held processing-stopped ---+
>>>> 10. PrintJobState: This looks like some sort of mapping of
> JobStateReasons, but it is very confusing. See my comments on #9 above, but
> this will be very difficult to map from a printer conforming to the
> Semantic Model (which is basically all printers).
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
--
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/20130417/fbabad40/attachment-0002.html>