Hi Ira,
It might be better if we keep discussions on this list to a discussion of
the MFD specific circumstance, and general questions of process
bending/revision to the SC list.
Depending upon how one looks at it, the MFD model is one project with
basically one set of requirements. It is a matter of practicality that it is
divided up into separate Service, (and support) specifications. The only
requirement for/of the 'Overall' spec beyond the general requirement for a
consolidated MFD model is the convenience of lumping common elements and
concepts in one place. I suggest that individual requirements documents
(whether or not they appear to be required by the Process document) or
sections detract from clearly stating that a major requirement is
consistency of modeling content and method among the services.
I am suggesting that the MFD Model requirements be considered, agreed to and
honored rather than be just some boiler plate text that we copy from some
other spec. But if the consensus of the MFD working group is that this is
not desirable, I will paste some nominal text in the 'Overall' document.
Bill Wagner
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Wednesday, October 28, 2009 1:19 PM
To: William Wagner
Cc: mfd at pwg.org
Subject: Re: [MFD] Issue for MFD teleconference Thursday 10/29?
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.