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%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.
>> _______________________________________________
> 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.