[MFD] Issue for MFD teleconference Thursday 10/29?

[MFD] Issue for MFD teleconference Thursday 10/29?

Ira McDonald blueroofmusic at gmail.com
Wed Oct 28 16:11:18 UTC 2009


Hi,

One important downside of a free-standing requirements
document (as we did for PSI) is that it has to be published
as PWG Informational (NOT standards-track), though it
still has to go through the PWG Last Call and PWG Formal
Vote process.

Unfortunately, the PWG Informational status makes it
invisible (it doesn't show on the PWG Standards list).

That's pretty much why we abandoned doing free-standing
requirements documents after the PSI project.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
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 Tue, Oct 27, 2009 at 8:11 PM, William Wagner <wamwagner at comcast.net> wrote:
> At the face to face, it was indentified that the MFD “Overall” document
> needed “ Requirements” section.
>
>
>
> The PWG process document says  “Prior to completion of the first Working
> Draft, a clear statement of requirements for the standard to be produced is
> required. A requirements statement documents the best effort collection of
> known requirements on a particular protocol, interface, procedure or
> convention. The requirements statement is important as it leads to a clear,
> common understanding of the goals, provides a guide for developing the
> standard, and can be used as a final test to measure the completeness of the
> resulting specification.  …”
>
>
>
> In  practice, the Requirements document has reverted to being a  section in
> the spec draft. And one such section exists in the Scan and Resource
> standards. However, I suggest that, in place of including a rather minimal
> Requirements section in each Service spec, the Overall Spec and the System
> spec, we do a separate but meaningful Requirements document for the set of
> MFD Service and supporting documents.
>
>
>
> I think a separate single Requirements document would not only be more
> efficient, but it would help readers understand why we are taking a much
> implemented device type and Services that have been around for many years
> and creating new and very involved model descriptions. I think a meaningful
> requirements document would indeed allow a “common understanding of the
> goals, provide a guide for developing the standard, and [a reference] to
> measure the completeness of the resulting specification.”
>
>
>
> I call the existing Requirements sections minimal since they consist of
>  Rationale, Out of Scope, and Model Mapping Conventions.  The ‘ Rationale’
> section takes the form “ There is  clear need to do this”, which appears
> rather circular. ‘Out of Scope’  is useful in providing bounds, but does not
> really help understanding what is in scope. “ Model Mapping Conventions”
> does not really appear to be a main aspect of requirements.
>
>
>
> The process document is unclear on whether “Requirements”  should be “
> Requirements for” (i.e.  why it is needed, Rational, Use Cases) or “
> Requirements of” (operational requirements, what must be addressed,
>  constraints, need for conformity with,  and out of scope). In the case of
> the MFD Service documents, the requirements should not necessarily relate to
> the requirements for or of the Service but rather the requirements for and
> of a model of the service consistent with an overall structure (I think… but
> I too need some help in clearly stating why the modeling is necessary.)
>
>
>
> So, I propose a separate  Requirements document and would like some help to
> really define the need for a consistent modeling of MFD services.  So far,
> the best I can find is in the charter “Currently service, device, and job
> management and job submission protocols for these network MFDs are
> fragmented and proprietary. “ Along with this would  be some requirements of
> the models (be representable in XML?  be consistent with IPP?  Be compatible
> with existing products?)…Pete and Ira seem to have a handle on this but I
> suspect that having a clear written statement may have limited the
> continuous evolution that we have been experiencing.
>
>
>
>  Of course, if no one is interested, I can just copy the standard stuff we
> have in the other specs and get this puppy rolling.
>
>
>
> Thanks,
>
>
>
> Bill Wagner
>
>
>
> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Zehler,
> Peter
> Sent: Tuesday, October 27, 2009 7:18 AM
> To: mfd at pwg.org
> Subject: [MFD] MFD teleconference Thursday10/29 at 3:00 PM EDT (12:00 PM
> PDT)
>
>
>
> As agreed at the recent face to face meeting there will be an MFD conference
> call at 3:00 PM EDT (12:00 PM PDT) Thursday October 29.  The focus of this
> meeting is the Copy specification that was not covered at the meeting.  The
> same document will be used.
>
>
>
>
>
> 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.
>
>
>
> Call-in toll-free number (US/Canada): 1-866-469-3239
>
> Call-in toll number (US/Canada): 1-650-429-3300
>
> Call-in toll number (US/Canada): 1-408-856-9570
>
>
>
> Attendee access code: (by request only, please contact me if you do not have
> it)
>
>
>
> Agenda:
>
> 1. Identify Minute Taker
>
> 2. Approval of minutes from last meeting
>
>         <ftp://ftp.pwg.org/pub/pwg/mfd/minutes/pwg-ftf-mfd-minutes-20091013-14.pdf>
>
>
> 3. Agenda bashing
>
> 4. Resolve PrinterResolution representation (PrintServiceCapabilities)
>
> 5. Discuss Media, MediaType and MediaCol representation in
> <service>DocumentProcessing and IPP/WS-Print mapping
>
> 6. Discuss Copy Service Semantic Model and Service Interface- Interim Draft.
>
> <ftp://ftp.pwg.org/pub/pwg/mfd/wd/wd-mfdcopymodel10-20091007.pdf>
>
> (also available is the “-rev” version as well as the “.doc” format for both
> versions)
>
> 7. Next steps
>
>
>
> Click Here to Join Live Meeting
>
> <https://www.livemeeting.com/cc/xerox/join?id=PWG_MFD&role=attend&pw=PQ%25%3EFj5sN>
>
>
>
>
>
>
>
> 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