Re: MFD> Scan Service Sectionr 10

From: Ira McDonald (blueroofmusic@gmail.com)
Date: Mon Feb 02 2009 - 17:32:26 EST

  • Next message: William A Wagner: "RE: MFD> Scan Service Sectionr 10"

    Hi Bill,

    I hope you're not suggesting we delete the state
    tables?

    We could certainly *bend* the operations (e.g., to let
    StartupScanService be an operation received by a
    ScanService in Initial / Down state).

    But in the real world of WSDL bindings, that won't work!

    A service can only receive an incoming WSDL (SOAP)
    request when it's ALREADY instantiated, addressable,
    and at least Down.

    I believe that our MFD Model should have a first-class
    System object that receives StartupService (with a param
    for what type of service) and DeleteService (to really
    remove a Down service instance).

    I do NOT see the problem with references to ISO 10175
    Part 1 (Printing Ops) and Part 3 (Admin Ops). This is the
    underpinning of most all IPP attributes and operations and
    therefore of the PWG Semantic Model v1.0 itself.

    Cheers,
    - Ira

    Ira McDonald (Musician / Software Architect)
    Chair - Linux Foundation Open Printing WG
    Blue Roof Music/High North Inc
    email: blueroofmusic@gmail.com
    winter:
      579 Park Place Saline, MI 48176
      734-944-0094
    summer:
      PO Box 221 Grand Marais, MI 49839
      906-494-2434

    On Mon, Feb 2, 2009 at 1:31 PM, William A Wagner <wamwagner@comcast.net> wrote:
    > Ira,
    >
    > Sorry, I am not following you. What I was attempting, in what little way I
    > can, is to have the Scan Service document at least consistent within itself.
    > If my attempt has been unsuccessful, I will most willingly drop the
    > suggested changes.
    >
    > I agree that it is good to also have the document consistent with related
    > documents; but one cannot assume that readers are all familiar with the
    > various other documents that you reference, at least not to the extent that
    > terms and concepts in those documents are common knowledge and need not be
    > defined (at least by reference.. but that can get cumbersome)
    >
    > The term "System" as a formal object is not defined in the Scan Service
    > document. The word system is appears to be used in a general sense, although
    > perhaps this is just my interpretation. Indeed, I wonder if these uses of
    > the word, although they may be derived from other definitive specifications,
    > make sense.
    >
    > 1831 Pending - the job has been accepted by the system and is
    > awaiting system resources before it can start processing
    >
    > 2276 Aborted - The Document has been aborted by the system, ...
    >
    > Neither does the Scan Service document use the term Startup Event (except
    > cryptically in the State table) although it does use Startup() in the State
    > Diagram and define StartupScanService as an (optional) operation. (How is
    > the service "created" if there is no Startup operation?)
    >
    > I find your explanation that "Startup *event* (not operation) arrives at the
    > Service object in Initial phase / Unknown state..." confusing considering
    > your statement that it is the "StartupScanService operation... sent to a
    > System (NOT a ScanService) that creates a new instance of a ScanService in
    > the Initial phase..." If StartupScanService creates a service, how can the
    > Startup *event* arrive at the Service...unless of course the Startup event
    > is a secondary result of the Startup operation, occurring after the
    > operation has already created the service. Or perhaps the Startup event is
    > completely independent from the Startup operation?
    >
    > But I really question whether all this is germane. I think it is important
    > for the specification define the external interfaces and how the service (or
    > system) responds to them. I think it desirable that the specification not be
    > self inconsistent or unnecessarily confusing. I think that attempts to
    > define the internal implementation beyond what is necessary to characterize
    > black-box behaiour are unnecessary, will usually be ignored, and may cause
    > the document to be ignored. This of course is just my opinion.
    >
    > Thanks,
    >
    > Bill Wagner
    >
    >
    >
    > -----Original Message-----
    > From: Ira McDonald [mailto:blueroofmusic@gmail.com]
    > Sent: Monday, February 02, 2009 10:51 AM
    > To: William A Wagner; Ira McDonald
    > Cc: mfd@pwg.org
    > Subject: Re: MFD> Scan Service Sectionr 10
    >
    > Hi Bill,
    >
    > The System object is defined in WIMS and also in SM/2.0 schema
    > and has been for years.
    >
    > Miracle happens is bad design - so MFD services that are created
    > AFTER the device is installed MUST be based on operations that
    > are targeted to the System object (same semantics as a Server
    > object in ISO 10175-Part3).
    >
    > My Note (1) says that Startup *event* (not operation) arrives at the
    > Service object in Initial phase / Unknown state, which exactly follows
    > the state transition tables and notes in ISO 10175-Part3.
    >
    > The alternative is to break with DPA and show that a Service object
    > comes into existence in the Initial phase / Down state (and receives
    > the Startup event). But that transition from Unknown to Down is the
    > one (in DPA) that does the one-time initialization of data structures.
    >
    > Cheers,
    > - Ira
    >
    > Ira McDonald (Musician / Software Architect)
    > Chair - Linux Foundation Open Printing WG
    > Blue Roof Music/High North Inc
    > email: blueroofmusic@gmail.com
    > winter:
    > 579 Park Place Saline, MI 48176
    > 734-944-0094
    > summer:
    > PO Box 221 Grand Marais, MI 49839
    > 906-494-2434
    >
    >
    >
    > On Mon, Feb 2, 2009 at 12:39 AM, William A Wagner <wamwagner@comcast.net>
    > wrote:
    >> Ira,
    >>
    >> 1. Yes, you had made the point before that StartupScanService was sent to
    > a
    >> (undefined?) system, not to the service that is being started. However,
    > the
    >> detailed state diagram (Fig 27) indicates that "Startup" takes the service
    >> from Down to Idle. There is no indication of what takes service from
    > Unknown
    >> to Down. From a practical state, I questioned the Unknown to Down state
    >> transition prior to going to Idle. To address StartupScanService, perhaps
    >> line 5 should read: "On creation by a StartupScanService request, the Scan
    >> Service enters its Initial phase..."? Would acceptable wording on Line 7
    >> be: "After successful initialization, the Scan enters the Online
    > state..."
    >>
    >> Pete's 22 Jan version includes RestartScanService so I expect that that
    >> should be mentioned.
    >>
    >> 2. I understand your distinction, but the detailed state diagram shows
    > that
    >> pause() and C.Critial effect the transition to Stopped. How about if we
    > keep
    >> it simple here in the text and just say "...either a Critical event is
    >> generated" and avoid getting into the specific notation of the detailed
    >> state discussion?
    >>
    >> Thanks,
    >>
    >> Bill Wagner
    >>
    >> -----Original Message-----
    >> From: owner-mfd@pwg.org [mailto:owner-mfd@pwg.org] On Behalf Of Ira
    > McDonald
    >> Sent: Sunday, February 01, 2009 10:28 PM
    >> To: William A Wagner; Ira McDonald
    >> Cc: mfd@pwg.org
    >> Subject: Re: MFD> Scan Service Sectionr 10
    >>
    >> Hi Bill and Pete.
    >>
    >> Bill - I like all of your new text.
    >>
    >> However, there are two serious problems in existing text:
    >>
    >> (1) Second paragraph at line line 5 of page 2 is just wrong
    >>
    >> It is a StartupScanService operation (spelled that way) sent
    >> to a System (NOT a ScanService) that creates a new instance
    >> of a ScanService in the Initial phase, causes self-test, and finally
    >> transition to Online phase / Idle state. The ScanService itself
    >> does NOT perform a start-up operation (line 7). It is handling
    >> the single E.startup *event* sent to it by the System (while in
    >> in the Initial phase / Unknown state).
    >>
    >> If we keep it, a RestartScanService operation could be sent
    >> to a ScanService (to recover from a Shutdown to Offline
    >> phase / Down state). See the notes on lines 1628 to 1639
    >> on pages 66 and 67 of lcrc-mfdscanmodel10-20090119.pdf
    >>
    >>
    >> (2) Recurring problem of reading the terms in state tables
    >>
    >> The notation key in the Scan Service spec for the state table
    >> is at line 1618 page 66 in lcrc-mfdscanmodel10-20090119.pdf
    >>
    >> For example at line 12 in page 2 of your draft, we see:
    >>
    >> "...either a C.Critical event is generated"
    >>
    >> The expression "C.Critical" means a *passive* Condition (C)
    >> (i.e., a ScanService.StateReasons value) is TRUE that a Critical
    >> alert is now pending. While, the expression "~C.Critical" means
    >> that any NOT (~) Critical Condition is now pending.
    >>
    >> The expression "E.Critical" means that an *active* Event (E)
    >> that is Critical has just occurred. Conversely "~E.Critical" means
    >> that any non-Critical (i.e., warning) event has just occurred.
    >>
    >> So "C.Critical event" is confused.
    >>
    >> Cheers,
    >> - Ira
    >>
    >> Ira McDonald (Musician / Software Architect)
    >> Chair - Linux Foundation Open Printing WG
    >> Blue Roof Music/High North Inc
    >> email: blueroofmusic@gmail.com
    >> winter:
    >> 579 Park Place Saline, MI 48176
    >> 734-944-0094
    >> summer:
    >> PO Box 221 Grand Marais, MI 49839
    >> 906-494-2434
    >>
    >>
    >>
    >> On Fri, Jan 30, 2009 at 4:26 PM, William A Wagner <wamwagner@comcast.net>
    >> wrote:
    >>> Considering the decisions at yesterday's conference call with respect to
    >>> "submitting a job", I modified the proposed rework of Section 10 of the
    >> Scan
    >>> Service document. This rework (only in markup) is posted as
    >>> ftp://ftp.pwg.org/pub/pwg/mfd/white/ScanServiceTheoryOfOp-revB.pdf.
    >>>
    >>>
    >>>
    >>> Thanks,
    >>>
    >>>
    >>>
    >>> Bill Wagner
    >>>
    >>>
    >>>
    >>> From: owner-mfd@pwg.org [mailto:owner-mfd@pwg.org] On Behalf Of Zehler,
    >>> Peter
    >>> Sent: Thursday, January 29, 2009 1:38 PM
    >>> To: mfd@pwg.org
    >>> Subject: MFD> Update to Agenda for MFD Teleconference, Thursday 1/29 3:00
    >>> EDT
    >>>
    >>>
    >>>
    >>>
    >>>
    >>> There will be an MFD conference call at 3:00 PM EDT (12:00 PM PDT) this
    >>> Thursday. The meeting is held in accord with the PWG Intellectual
    >> Property
    >>> Policy.
    >>>
    >>>
    >>>
    >>> Note the NEW Teleconference number and access code are now used.
    >>>
    >>> Please contact me if you do not have the new number and pass code.
    >>>
    >>>
    >>>
    >>> Agenda:
    >>>
    >>> 1. Identify Minute Taker
    >>>
    >>> 2. Approval of minutes from last teleconference
    >>>
    >>>
    >> <ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-mfd-minutes-20090115.pdf>
    >>>
    >>> 3. Agenda bashing
    >>>
    >>> 4. Discuss syntax of JobPhoneNumber on line 2182 of Scan specification
    >>>
    >>> 5. Discuss open ended REQUIREMENT governed by a third party (End User)
    >>> policy on line 2788-2790 of Scan specification
    >>>
    >>> 6. Discuss Bill's comments on in Resource Service
    >>>
    >>>
    >>>
    >>
    > <ftp://ftp.pwg.org/pub/pwg/mfd/white/nancy-Proposed-Resolution-for-Bill-W-co
    >> mments-for-Resource-Service-20090127.pdf>
    >>>
    >>> b) Discussion of Testing State, transition in and out, and method
    > of
    >>> transition Part of both Resource and Scan Service discussion)
    >>>
    >>> 7. Discussion on Scan Service State and proposed change to section 10 of
    >> the
    >>> specification
    >>>
    >>> a) Chose between the existing text, proposed text or arrive at some
    >>> other consensus.
    >>>
    >>> Existing text is section 10
    >>> <ftp://ftp.pwg.org/pub/pwg/mfd/wd/lcrc-mfdscanmodel10-20090122.pdf>
    >>>
    >>> Proposed change is available at
    >>> <ftp://ftp.pwg.org/pub/pwg/mfd/white/ScanServiceTheoryOfOp.pdf>
    >>>
    >>> 8. Discuss any comments on the Resource Service interim draft. Objective
    >> is
    >>> to move to the Last Call version for review at the Face to Face.
    >>>
    >>>
    >> <ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdresourcemodel10-20090115.pdf>
    >>>
    >>> 9. Next steps
    >>>
    >>>
    >>>
    >>> Click Here to Join Live Meeting
    >>>
    >>
    > <https://www.livemeeting.com/cc/xerox/join?id=PWG_MFD&role=attend&pw=PQ%25%3
    >> EFj5sN>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>>
    >>> Peter Zehler
    >>>
    >>> Xerox Research Center Webster
    >>> Email: Peter.Zehler@Xerox.com
    >>> Voice: (585) 265-8755
    >>> FAX: (585) 265-7441
    >>> US Mail: Peter Zehler
    >>> Xerox Corp.
    >>> 800 Phillips Rd.
    >>> M/S 128-25E
    >>> Webster NY, 14580-9701
    >>>
    >>>
    >>
    >>
    >
    >



    This archive was generated by hypermail 2.1.4 : Mon Feb 02 2009 - 17:32:52 EST