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.