From: nchen@okidata.com
Date: Wed Aug 15 2007 - 14:07:47 EDT
Hi Glen,
Thanks for the comments. Please see my reply for the three questions in 
blue text below. 
The rest of the comments are for rewording or better definitions for the 
cited locations in the draft, I'll reflect them in the updated draft for 
the next teleconference.
-Nancy
"Petrie, Glen" <glen.petrie@eitc.epson.com> 
Sent by: owner-mfd@pwg.org
08/14/2007 07:10 PM
To
mfd@pwg.org
cc
Subject
MFD> some comments on the MFD req doc
All,
I would like to get feed back on my initial review of the definition 
section
in the requirement document.   If I have the wrong understanding of these, 
I
may interpret the remainder of the document out of context.
Page : Line             Comment
6 : 168-169     Are we only considering office and production 
environments?
Are there any additional considerations for environment or applications 
such
public access or hand-held device environments?  Is there is a case of a
public access scan-service? Is there is a case of pda/phone interfacing 
with
an MFD.
NC> Currently the use case we have from members only considering office 
and production environments I believe. We have not received any request 
for considering the other environments you mentioned above. I would like 
members who are interested in other environments, please provide their use 
cases for consideration.
6 : 169 What is an  "... on-ramp ..." ?   "document on-ramp scanning" -->
"document scanning".
NC> "document on-ramp scanning" here is a process that scans hardcopy 
documents and then sends the scanned document to the next stop of a 
document workflow application. This 'next stop' could well be a document 
management system or document repository or any processing component of 
the document workflow application.
"On-ramp" has been used in our industry in many cases to mean for 
deliverying to some other different remote, more complex system in many 
cases through some sort of gateway, as analogous to hopping onto some sort 
of 'bridging' station or large destination, also implicating with the use 
of some effort.
6 : 171-172     Is the interruption of a scan job based on the size
(large/small) or is it based strictly on priority?  I would say strictly 
on
priority.
NC> Yes, it's based on priority.
6 : 172 The statement the "... model can support..." implies an optional
support issue.  That is an implementation decision; but the model will
either support something or it doesn't.  So if we're supporting this, then
6 : 172 Suggest rewording; " For multi-document batch scanning, the model
can support..." to The model support multi-document batch scanning...".
6 : 173 "When necessary, the model can be extended to support..." Again, 
the
" The model supports..." and decision on whether is does or not is an
implementation detail.   If the model, in this version of the document, 
will
not support security then the statement should be removed.
6 : 178-180     The statement starting with "Currently ..."  I believe 
could
be removed.
6 : 190-192     "Scan Job Ticket" "Scan Job Ticket (software)..."
Add new definition for a physical Scan Job Ticket that is placed on
the scanner.
"Scan Job Ticket (physical) - A encoded sheet of paper the
contains... (same as "Scan Job Ticket (software)..." ) (new last sentence)
The content of the physical scan job ticket is configured by the user
through direct markings on the encoded sheet of paper."
6 : 194 Can there be a physical Scan Job Template?   Like a fax cover 
sheet,
it is located near the MFD.  The user fills out the template (instantiates
the template to the physical Scan Job Ticket) and then places it on scan
with their document.
6 : 205 Scan Service -  The process of accepting a Scan Job Ticket and 
based
the Scan Job Ticket will setup the scan device, invoke a physical scan
operation of a hard copy document and store the digital output.
(Comments:
1.      Scan Service in itself is not the
"process of converting...."; that is physical process of the 
photo-detector;
I am assuming the service is a software service and therefore the service 
is
the controller.
2.      The scan hard copy document may not
result in a digital image as the final retrievable state.  For example, a
scan service may before OCR and the user (scan service) may not ever have
access to the "scanned image".  Therefore, "digital output" covers the 
gamut
of possibilities.  The input document may contain bar-codes that 
processed'
etc.
6 : 205 is a "digital document" all encompassing of both digital image
and/or digital text?  Is the phrase "digital content" better?
6 : 216 Since an image is not the only possible digital output
"paper document being scanned" -> " scanned hard copy document".
6 : 221 "processing" is only post-process to the scan operation.  "Scan
Intent - The preferences of the user for scanning, processing and storing 
of
a scan job."  Isn't that just what a "Scan Job Ticket" is?
6 : 224         Isn't the "scan client" either the MFD user interface or 
the
app on the pc setting up the Scan Job Ticket.  The Scan Service is the app
(manager/controller) on the scan device executing the Scan Job Ticket.
Rgds,
Glen W. Petrie
Epson Imaging Technology Center
2580 Orchard Parkway, Suite 200
San Jose, CA, 95131
Voice: 408.576.4131  Fax: 408.474.0511
This archive was generated by hypermail 2.1.4 : Wed Aug 15 2007 - 14:07:57 EDT