From: Ira McDonald (blueroofmusic@gmail.com)
Date: Mon Feb 02 2009 - 10:50:52 EST
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 - 10:51:02 EST