Re: MFD> some comments on the MFD req doc

From: nchen@okidata.com
Date: Wed Aug 15 2007 - 14:07:47 EDT

  • Next message: Petrie, Glen: "MFD> more comments on requirements doc"

    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



    • text/html attachment: C.htm


    This archive was generated by hypermail 2.1.4 : Wed Aug 15 2007 - 14:07:57 EDT