Subject: [IPP] Vacation schedule for IPP/Cloud Imaging calls

From: Ira McDonald <[email-masked]>
Date: Mon, 13 Jun 2011 15:14:59 -0400

Hi,

We just decided during our IPP WG meeting that we will skip
two weeks:

- Monday 20 June 1-3pm EDT - Cloud Imaging WG
- Monday 27 June - CANCELED
- Monday 4 July - CANCELED
- Monday 11 July 1-3pm EDT - IPP WG

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Christmas through April:
  579 Park Place  Saline, MI  48176
  734-944-0094
May to Christmas:
  PO Box 221  Grand Marais, MI 49839
  906-494-2434

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "William Wagner" <[email-masked]>
Date: Wed, 15 Jun 2011 15:22:08 -0400

Considering the Cloud Imaging scenario discussion  of June 6 and the IPP
scenario discussion of June 13, as well as face to face discussions, perhaps
I have just missed the point but it seems we have wandered about in circles
(which is to say that we apparently have concluded that our first approach
was correct, which it may be). Dealing with the "Best Practices" document,
we have concluded that there need be just one scenario for each of the
imaging functions: print, scan and fax.  This "Scenario" becomes basically
just a very general statement of what is involved in printing, or faxing, or
whatever;  I suggest that although it may be a useful starting point, it
does not provide the usefulness of a more detailed  scenario. 

Further, it seems that two different approaches have been proposed  about
how the "use cases"  will be extracted from this single "scenario".  One is
a sort of horizontal approach by which  each of the basic steps of the
scenario refers to a set of use cases; for example, "Selecting a Printer" ,
"Submitting a Print Job", etc.   The other, perhaps best described as
vertical approach, would be to outline sequences of how a user in a
particular situation would print, sort of a narrow scenario something like
the use cases that were first submitted. 

Granted that we can use whatever terms we wish, provided that we properly
define them,  I do think that in using common engineering development terms
we should not deviate too much from accepted usage. I suggest looking at 

http://en.wikipedia.org/wiki/Scenario_%28computing%29 and
http://en.wikipedia.org/wiki/Use_case, or perhaps the more formal documents
referenced by these articles. 

But calling it scenario or use case, I do think that one of the main
benefits of outlining a realistic start-to-end sequence (from "I want to
print something" to "I know  that that  something was printed and where it
was output") is that one sees (and reviewers see) interactions that might be
lost in a purely horizontal approach . What is more, people can follow a
realistic sequence and the use cases can become, as Randy suggested they
must be, more "compelling".

In short,  I suggest:

1.     Our terminology be not inconsistent with typical design terminology

2.     We define our approach and terminology in the "Best Practices"
document

3.     We be consistent in terminology and level within the "Best
Practices" document and among the various projects (It would be very
confusing to have a Use Case in one document become a Scenario in another.)

4.     We not lose the "story" aspect and the  sequence of what the user
does and what the "system" must do. Joe is on vacation at Yellowstone and
needs to print out the map to a lost gold mine in Wyoming that his friend in
New York City just found. Perhaps the story is farfetched, but it includes
many aspects of the general problem that must be considered. 

Thanks,

Bill Wagner

---

From: Michael Sweet <[email-masked]>
Date: Sun, 19 Jun 2011 23:38:39 -0700

On Jun 15, 2011, at 12:22 PM, William Wagner wrote:
> ... 
> 2.     We define our approach and terminology in the “Best Practices” document
> 3.     We be consistent in terminology and level within the “Best  Practices” document and among the various projects (It would be very confusing to have a Use Case in one document become a Scenario in another.)
> 4.     We not lose the “story” aspect and the  sequence of what the user does and what the “system” must do… Joe is on vacation at Yellowstone and needs to print out the map to a lost gold mine in Wyoming that his friend in New York City just found. Perhaps the story is farfetched, but it includes many aspects of the general problem that must be considered.

I agree on all points.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Ira McDonald <[email-masked]>
Date: Mon, 20 Jun 2011 10:19:06 -0400

Hi Bill and Mike,

I also agree on all points.

The ultimately broad scenario (one for all Print) doesn't really
work well, IMHO.

Cheers,
- Ira

On Jun 20, 2011 at 2:38 AM, Michael Sweet <[email-masked]> wrote:

> **... **
> In short,  I suggest:****
> ****
> 2.     We define our approach and terminology in the “Best Practices”
> document****
> 3.     We be consistent in terminology and level within the “Best
> Practices” document and among the various projects (It would be very
> ****
> 4.     We not lose the “story” aspect and the  sequence of what the user
> does and what the “system” must do… Joe is on vacation at Yellowstone and
> many aspects of the general problem that must be considered.****
>
>
> I agree on all points.
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
> cloud mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/cloud
>
>