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

[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 20:33:25 UTC 2009


Hi Bill,

Your reply is confusing.

The only way that "Requirements may be updated during
development..." in an external document is the entire PWG
Initial/Interim/Prototype/Stable/LastCall/FormalVote process
(minimum 6 months, usually more than a year) - that's worse
for timeliness than an embedded Requirements section.

And I find your attack on Power Model for not having a first
Power Management Requirements document rather out of
proportion.

I personally have written ALL of the Requirement sections
and specs in the PWG since PSI (last 5 years).

Before I ever proposed the first Power Model sketch in June,
I evaluated four vendor private MIBs (publicly available ones),
DMTF CIM (and their extensive Power Profile), ACPI, IEEE
1621, and three large user scenarios within Samsung (not
publicly available).

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 Wed, Oct 28, 2009 at 2:33 PM, William Wagner <wamwagner at comcast.net> wrote:
> Ira,
>
> This discussion is more appropriate to the SC list.
>
> But note that the "Process" document states that "Requirements may be
> updated during the development of the standard, as they become clearer.", so
> the process addresses the potential issue of "stale" (or more likely,
> incompletely considered) requirements. But what it also does is discourage
> generating solutions to problems perceived but not clearly delineated.
>
> I agree that the "stawman" approach of generating a spec draft, getting
> comments, and writing the requirements later is often more expeditious, but
> it can go awry for more complicated projects.
>
> Although I threatened to unilaterally generate a Power Management spec, I
> really would have preferred doing a good requirements analysis of Power
> Management before you submitted your first draft of solutions.(But perhaps
> we would not have had much participation, as the results of the survey
> suggested.)
>
> Bill Wagner
>
> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Wednesday, October 28, 2009 1:40 PM
> To: Zehler, Peter; Ira McDonald
> Cc: William Wagner; mfd at pwg.org
> Subject: Re: [MFD] Issue for MFD teleconference Thursday 10/29?
>
> Hi Pete,
>
> I agree that we can administratively improve the visibility
> of our free-standing Requirements specs.
>
> But I still think the "last year's news" effect of a static external
> Requirements spec is a real downside.
>
> In the Power Management Model, there has been repeated
> update of Requirements in both Use Cases and Design
> Requirements sections.
>
> And relevant Use Cases are important and evolving, by their
> very nature.
>
> 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 Wed, Oct 28, 2009 at 1:22 PM, Zehler, Peter <Peter.Zehler at xerox.com>
> wrote:
>> Ira,
>> If we do go with a free standing requirements document it certainly will
> be visible from the MFD page as is the Scan Service requirements document.
>  There is a link of the main PWG page for informational documents.  Based on
> its contents it could use a bit of updating.  Once that is addressed the
> informational documents should be just as visible as the standards.
>> 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
>>
>> -----Original Message-----
>> From: mfd-bounces at pwg.org [mailto:mfd-bounces at pwg.org] On Behalf Of Ira
> McDonald
>> Sent: Wednesday, October 28, 2009 12:11 PM
>> To: William Wagner; Ira McDonald
>> Cc: mfd at pwg.org
>> Subject: Re: [MFD] Issue for MFD teleconference Thursday 10/29?
>>
>> 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%3
> EFj5sN>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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.
>>
>> _______________________________________________
>> 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