[MFD] Issue for MFD teleconference Thursday 10/29?

[MFD] Issue for MFD teleconference Thursday 10/29?

[MFD] Issue for MFD teleconference Thursday 10/29?

Ira McDonald blueroofmusic at gmail.com
Wed Oct 28 17:18:45 UTC 2009


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.




More information about the mfd mailing list