From: William A Wagner (wamwagner@comcast.net)
Date: Mon Feb 02 2009 - 13:31:37 EST
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 - 13:32:59 EST