Agreed. On the other hand:
1. Going through a formal vote process on the requirements does assure that
there is a minimum number of members who agree with (and other members who
are aware of and have had an opportunity to object to) the requirements for
and of the effort, perhaps avoiding the scramble to get comments during the
development and votes on the balloting on the document.
2. The requirements document is preparatory to the specification document.
The Specification document hopefully identifies the requirements either
implicitly or explicitly, so that there would be little need for the
separate requirements document after the specification document is complete.
But I suggested the single unified requirements document for the MFD set as
a guide and simplification of the remaining Service documents, applicable
since there is a set of inter-related documents. I think the requirements
are the same for each service specification, yet some requirements must
apply to the set as a whole. That is, the modeling approach (and other
things) must be consistent across all documents.
The question of the advantages/desirability of bending the process is more a
subject for the SC... including a consideration of whether the process
document be revised.
Bill Wagner
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
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.