From: Ira McDonald (blueroofmusic@gmail.com)
Date: Mon Feb 02 2009 - 17:32:26 EST
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