As requested, I am outlining some of the differences between the IPP
Everywhere Use Cases and the revised Cloud Use Cases. First, since the
general position has been that, as a nonvoting member, my comments do not
count toward the quorum, I make these observations on IPP Everywhere vs.
Cloud "Use Cases" as comments on the conference call rather than last call
comments on the document. Second, I am noting the divergence of the two use
cases from the same original set not as critical comments on the IPP
Everywhere Use Cases, but to indicate the legitimate differences in how one
looks at these cases. I can think of no reason why the two sets of use cases
must be the same in style, form or specifics, provided that they are
realistic and useful in developing requirements. Further, I believe it is
valid to conclude that a requirement evolving from a Use Case need not be
addressed in thesolutions, provided that a reason for the omission is given.
However, in that there were some issues that came up in addressing the IPP
Everywhere use cases that had also been addressed in the Cloud Use Cases, I
offer this summary.
With that preface, I would note that the original Use Cases included both
concise statements of cases where a specific feature would be used (which I
would call Use Cases), and narratives giving a more or less plausible
situation (perhaps better called scenarios). The IPP Everywhere spec gives
specific use cases under "Select Printer" , but reverts to more of a
scenario approach for the "Print" section. I see no problem with this
approach although I admit a bias toward stating scenarios, with the
requirements developed from the scenarios breaking out the details (e.g.,
specific criteria used for selection).
One line of thinking in the Cloud discussion was that requirements were to
be developed to address use cases (or scenarios) and the design was to be
developed to satisfy the requirements. Therefore, it seemed inappropriate to
describe the Use Cases in terms of the elements of the model design. So the
Cloud scenarios were rephrased in terms of the basic elements.the User (or
more specifically, the potential Job Originator), the physical printer and
the stuff in between (primarily the Cloud , the big black box in the sky).
I do not suggest this as a comment on the IPP Everywhere specification, just
as the thoughts that are reflected in the Cloud Rationale section.
With regard to specific changes in the Cloud vs IPP Everywhere versions of
what was initially the same use case:
1. If Common Preconditions in Cloud were important, it was felt that
they should be itemized and presented as a distinct section. Once they were
made more obvious, they were variously considered to be wrongly stated,
obvious, or more appropriately stated in the requirements section. We are
not sure what we will do with them.
2. Objections to the Common Preconditions also stemmed from the
confusion of the term "Visible". Even in IPP Everywhere, it is sort of
contradictory to say "the Printer must be Visible to the Client in order to
be selected, either directly or through an intermediate Service" when
"Visible" is defined as the ability to communicate directly. The other
confusion developed from the definition's referring to the "ability" to
communicate, suggesting that at some time under some conditions the
connection could exist while the normal sense of the word suggests that the
connection does exist.
3. Print a Document - no significant difference. Original statement
specifying some relationship of user to printer was considered confusing and
was removed. Comments on validating were considered perhaps part of
requirements or solution.
4. Print by Reference. - same comments as Print a Document
5. Print a Photo/Print Using Loaded Media. - Titles diverged some
time ago. Preconditions were considered more requirements.
6. Check printing - Cloud sought to clarify that this did not involve
sending a "form template" to the printer. Also, to include an obvious Cloud
scenario, the application is Cloud Based (not necessary for IPP Everywhere).
I suggest that, in the IPP Everywhere text, Client sends the "document data
containing the checks" might be confusing, since check usually refers to the
printed media.
7. Print with Special Formatting was dropped from Cloud as not
representing a sufficiently distinct set of requirements.
8. The original Prescription print case in Cloud was changed to a
photoprint involving selection on the basis of geographic location and print
to someone other than the job originator. The prescription case seemed too
loaded with HIPAA problems.
9. Print and Select was changed to avoid reference to 'FollowMeR" (a
registered trademark of Ringdale)
10. Print to a Service - aside from some minor clarification, no change.
11. Job Cancel.that is canceling a job request after it has been submitted
and accepted was taken as a use case rather than an exception. This may be
more appropriate for Cloud since the Cloud model does require intermediaries
between the job originator and the printer.
12. Exceptions: Main change was identifying the exception but not the
actions to be taken, under the premise that the way the system reacts is to
be indicated under Requirements and how it does this is to be in the Model.
I would note that Pete indicated that there are User use cases (rather than
just Job Originator use cases) that have not been covered and may be added,
but that is a Cloud problem.
Aside from things that have already been noted in yesterday's call, I do not
think that the divergence in how the use cases are presented represents a
problem. But perhaps some of the wording (such as the treatment of "Print
and Select") may be of interest when addressing similar issues in IPP
Everywhere.
Thanks,
Bill Wagner
Thanks,
--
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/ipp/attachments/20120821/92497b72/attachment-0001.html>