MFD> section 3.3.1.4 proposed change

MFD> section 3.3.1.4 proposed change

nchen at okidata.com nchen at okidata.com
Thu Sep 6 13:41:39 EDT 2007


Hi Glen,

Thanks for the update.

> Is this the use case where the user simply
goes up to the scanner subunit, put their document in the scan and presses
the start button?   In other words is this supposed to be the simplest
use-case and the Local Scan Client performs the default action of creating 
a
user scan job template/ticket.

NC>> As far as I remeber when we discussed in April meeting and later 
teleconferences, there are two possibilites:
(1) The MFD does not have a UI at all - in this case, there is no way for 
user to walk up and enter 'job ticket identifier', The system default 
template is used.
(2) The MFD has a UI for user to enter 'job ticket identifier' which may 
be used to identify the user's default template.

Therefore I think (1) should be considered as the "basic" case, and (2) 
should be optional for vendors that provide a UI. Let's decide as a group 
in today's teleconference.

Thanks,
-Nancy
-------------------------------------------------------
Nancy Chen
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856) 222-7006
email: nchen at okidata.com




"Petrie, Glen" <glen.petrie at eitc.epson.com> 
Sent by: owner-mfd at pwg.org
09/06/2007 12:19 PM

To
mfd at pwg.org
cc

Subject
MFD> section 3.3.1.4 proposed change






Action Item --

6.      The flow steps for the "Walk-up Scan and Store Document" use case
will need to be updated according to the clarification between MFD/local 
UI,
scan client, and scan service discussed above
[see:pwg-mfd-minutes-20070830.doc]. Glen will update the flow steps.



Glen's Comment ---

I'm still a little confused.  Is this the use case where the user simply
goes up to the scanner subunit, put their document in the scan and presses
the start button?   In other words is this supposed to be the simplest
use-case and the Local Scan Client performs the default action of creating 
a
user scan job template/ticket.   If so, then any reference to "job ticket
identification" or "job ticket identifier" should be dropped from my
proposed change.


Original -------------------

Section 3.3.1.4

Walk-up Scan and Store Document -
A user walks up to a MFD, places his/her original paper on the platen,
enters his scan job ticket identification and then pushes the start 
button.
The default job template is copied into a transient scan job template. The
scan job template which was pre-created by an administrator (could be for 
a
security reason) may then optionally be used to modify the transient job
template which may be a copy of a default job template. When the user 
pushes
the scan button, a scan job is created and bound to the scan job ticket, 
and
the document on the platen or ADF is physically scanned. When scan 
document
is complete, it is sent to a specified document repository (in MFD or a
remote system).

Processing Flow Step Requirements
The following flow steps have been identified as requirements for this 
usage
scenario.

Step 1. User puts document on scanner.
Step 2. User MAY get a list of templates from scan service UI and select a
template. Scan service MAY modifies the
copy of template it has created from the defaults.
Step 3. User pushes green button. A scan job is created. The template is
copied into job ticket, and the scan ticket is  bound to the job. At this
point, the scan job is implicitly scheduled.
Step 4. The physical document is scanned and
associated with the document object. One or more document data files
are output from the single document
object associated with the scan job.
Issue - How should single document data file or multiple document data 
files
output from the single document object be indicated in scan job ticket? We
need an emlement in scan job ticket to indicate 'single' or 'multiple'
document output mode for the scan job. (NC) -> Resolution: See additional
design requirements in Section 3.3.1.3.2
Step 5. Document data is stored internally or in a remote
repository. The document storage location shall be
globally addressable by the scan service within an enterprise network.
Step 6. An EndOfJob event is sent to the user. The job status can
also be queried via the GetScanJobElements
request to determine scan job completion status. There shall be a scan
service counter in the job status       element that can be used to
determine the scan job progress before completion..


Proposed Change -------------------------

Original -------------------

Section 3.3.1.4

3.3.1.4 Walk-up Scan and Store Document -
A user walks up to a MFD, places his/her original paper on the platen,
enters his scan job ticket identification and then pushes the start 
button.

3.3.1.4.1 Processing Flow Step Requirements
The following flow steps have been identified as requirements for this 
usage
scenario.

Step 1. User places hardcopy document on platen or ADF (automatic document
feeder).
Step 2: Using the Local Scan Client, the user enters their scan job ticket
identifier.
Step 3: The user presses the start button
Step 4: The Local Scan Client copies the default scan job template into a
user's scan job template.
Step 5: The Local Scan Client sends the user's scan job template to the
Local Scan Service
Step 6: The Local Scan Service instantiates the scan template to a scan 
job
ticket.
Step 7: The Local Scan Service instantiates a scan job and bound the job 
to
the previously created scan job ticket, then schedules the user scan job.
Step 8: The Local Scan Service executes the user's scan job.
Step 9: The Local Scan Service stores the digital document at the specific
storage location.
Step10: The Local Scan Service notifies the MFD Scan Client that the scan
job is complete.
Step11: The Local Scan Client notifies the user the scan job is complete
based on the information in 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/mfd/attachments/20070906/2363a17d/attachment.html


More information about the Mfd mailing list