[MFD] Overall MFD Document

[MFD] Overall MFD Document

[MFD] Overall MFD Document

Ira McDonald blueroofmusic at gmail.com
Mon Jan 11 14:02:56 UTC 2010


Hi Bill,

I haven't got any time this week to explore the latest
SM/2.0 XML schema, but...

If the power elements aren't named and scoped
exactly like the PWG Power Mgmt Model, then
the MFD Overall (and the XML Schema) should
be corrected accordingly.  Power Model places
normative requirements on the representation
of the power elements in XML schema.

(I know Pete took these elements first from Power
MIB, not the Power Model - in both, several of the
properties have been renamed since November
for clarity and some properties have been added)

Cheers,
- Ira

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



On Sun, Jan 10, 2010 at 8:50 PM, William Wagner <wamwagner at comcast.net> wrote:
> I have updated the MFD Overall Document to include the Delay  and Power
>  elements as they appear in the schema. These additions as well as the
> previous changes are intended subjects for this week’s MFD conference call.
> The updated posting are:
>
>  ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100111.pdf and
>
> ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100111.doc
>
>
>
>
>
> Thanks,
>
>
>
> Bill Wagner
>
>
>
> From: William Wagner [mailto:wamwagner at comcast.net]
> Sent: Wednesday, January 06, 2010 3:49 PM
> To: 'mfd at pwg.org'
> Subject: Overall MFD Document
>
>
>
> Happy New Year!
>
>
>
> I have posted an update to the Overall MFD Model document, reflecting those
> issues from the December face-to-face that I can address.
>
>
>
> ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdoverallmod10-20100104.pdf
>
>
>
> Note some schema diagrams need updating and are awaiting a new schema post.
> Other items also remain open.
>
>
>
> MS Word continues to be difficult, especially in screwing up cross
> references.
>
>
>
> In addition to highlighting some new text, there are some comments that, to
> avoid balloons, do not show up. They are as follows:
>
>
>
> C1
>
> Paragraph 2.3 Needs to be reworked to reflect schema changes.
>
> C2
>
> Table 17.Keyword for Feed direction?
>
> C3
>
> Section 7.3  originally followed the pattern of Scan and Resource specs,
> although additional operations added have had descriptions derived from IPP
> corollaries. However, operation attributes, error messages etc have not been
> discussed. Should they be?
>
> Note that some new operation descriptions have been added.
>
> C4, 5, 6, 8, 9, 10
>
> Service Operations in 7.3.2: Since there can be multiple instance of a given
> service type, need the request identify the instance? If so, how?
>
> C7
>
> Para 7.3.2.8 New writeup
>
> C 11
>
> Para 7.3.2.18 The IPP spec includes processing stopped as a valid state from
> which to suspend a job. Is a job in Processing Stopped considered a current
> job? If any Job is in Processing Stopped, is the operation considered
> successful? Following paragraph says no.
>
> C12
>
> Para 7.3.2.18  If the JobID is included and it is one of several jobs in
> processing, I assume only the ID'd job is suspended?
>
>
>
> Thanks,
>
>
>
> Bill Wagner
>
>
>
>
>
> From: Zehler, Peter [mailto:Peter.Zehler at xerox.com]
> Sent: Wednesday, January 06, 2010 12:49 PM
> To: William Wagner; mfd at pwg.org
> Subject: RE: [MFD] Job State Transition Diagram error
>
>
>
> Bill,
>
> My only points for the items below was that
>
> 1)      System configuration or conditions can cause the transition as well
> as an operation
>
> 2)      Job operations or conditions can affect this transition change for a
> specific job just as well as service wide operations or conditions can
> affect this job transitions.
>
> The issue was raised by an implementer that was unsure if a required
> resource would affect the state of a pending job.
>
> Pete
>
>
>
>
>
> Peter Zehler
>
> Xerox Research Center Webster
> Email: Peter.Zehler at 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
>
>
>
> From: William Wagner [mailto:wamwagner at comcast.net]
> Sent: Wednesday, January 06, 2010 12:36 PM
> To: Zehler, Peter; mfd at pwg.org
> Subject: RE: [MFD] Job State Transition Diagram error
>
>
>
> Yes. Right now, the transition effectors are indicated by italicized general
> statements (e.g., Job Completed) or citing actual operations (CreateJob).
>  Although it would be useful to indicate how each transition  may be
> effected by an operation, that would probably render the diagram unreadable.
> Further, we appear to be constantly adding more operations and now operation
> attributes that affect Job State. My inclination is to replace all remaining
> operation transition effectors with generic statements; e.g., HoldJob
> Request becomes Job Held. The correlation between the general statements and
> the transition  effectors (Operations, Processing Events,  Problem Events,
> Operation Attribute enabled Events) would be dealt with elsewhere (perhaps
> in the descriptions of Operations).
>
>
>
> That does bring up another question.  How many more of the IPP operations
> will be re-stated as  <service> Operations? I have attached (if it gets
> through)  a table of IPP operations (derived from the recent IPP work)
> versus MFD Operations as they now are listed, with my understanding of
> correlation.  I think it best to resolve the discrepancies now.
>
>
>
> Thanks,
>
>
>
> Bill Wagner
>
>
>
> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Zehler,
> Peter
> Sent: Wednesday, January 06, 2010 8:03 AM
> To: mfd at pwg.org
> Subject: [MFD] Job State Transition Diagram error
>
>
>
> All,
>
>
>
> The diagram for the Job State transition is incorrect.
>
> 1)      The transition from Pending to PendingHeld only shows the HoldJob
> event.  According to the definition of the PendingHeld state “the job is not
> a candidate for processing for any number of reasons and will return to the
> Pending state when the reasons are no longer present”.  An example could be
> an unavailable resource.
>
> 2)      The transition from Processing to ProcessingStopped says “Service
> Stopped”.  I believe that it should be “Job or Service Stopped”.  The
> commands Suspend<service>Job and Resume<service>Job cause the transitions.
> A required resource or a critical fault will cause the transition to
> ProcessingStopped.  The resource becoming available or clearing the critical
> fault can cause the reverse transition.  The currently described Service
> conditions for the transition remain valid.
>
>
>
> Pete
>
>
>
>
>
> Peter Zehler
>
> Xerox Research Center Webster
> Email: Peter.Zehler at 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 message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> _______________________________________________
> mfd mailing list
> mfd at pwg.org
> https://www.pwg.org/mailman/listinfo/mfd
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




More information about the mfd mailing list