Hi Bill,
(1) MFD Overall Model is standards-track - so it HAS to
have embedded or external Requirements spec itself.
(2) An embedded full Requirements section ensures that
new requirements identified DURING the interface spec
development can be included and addressed - while a
free-standing Requirements document is static and
never updated (in practice), so it tends to be out-of-date.
(3) Changing the PWG Standards Process (for what?) has
a very long tail in time - roughly one year minimum.
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 12:59 PM, William Wagner <wamwagner at comcast.net> wrote:
> 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.
>> _______________________________________________
> 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.