Hi Randy,
Although I agree that we have spent much too much time on the Rationale, I
cannot agree that the section should be dropped. And in this case we are not
working backwards on Requirements. The requirements were outlined some time
ago and we are recently recovered from someone else's contention that they
were not necessary. Now we are spending more time on stylistic issues.
But we do have a basic format for specifications, and there are reasons for
Rationales to be in it. One is for others who have not participated in the
spec generation to understand fairly clearly what the subject being
specified is to do. The other is to keep the group generating the spec
focused on what is to be addressed and what is not. The tendency to expand
features is exceeded only by that to gloss over realities. It is a
reasonable test of a specification to look at the use cases after the basic
design is described and check if the solution addresses the use case.
Indeed, the original design has evolved a bit on the consideration of use
cases, and I suspect that there will be more changes as we continue to
consider complications in what we want to do.
I intend to 'crisp up' the use cases as was discussed at the f2f meeting,
and I expect that to be the end of it (unless we decide to change our
objectives). My own feeling is that interesting information will be lost in
this process, but hopefully it will quiet the objections and we can get on
with the rest of the spec.
Bill Wagner
-----Original Message-----
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Tuesday, June 04, 2013 2:14 AM
To: cloud at pwg.org
Subject: Re: [Cloud] Minutes posted from today's conference call
Hi guys,
I'm looking at the May 8th cloud imaging model and requirements, with an eye
towards revisiting the use-cases and requirements.
Looking at the document, it appears that we have already "designed" how the
system is supposed to work, so I'm not sure if use-cases or requirements
even need to be documented at this point.
I'm not saying that's a bad thing, I'm just saying that we basically already
know how the system is supposed to work, and working backwards on
requirements and use-cases may not be the best use of our time.
In my experience, the order of operations goes something like:
1. BOF (ok, this sounds like something useful, let's get started)
2. Use-Cases
3. Requirements (somewhat detailed, derived from use-cases)
4. Functional Specification (how the system is supposed to work, which is
much of what we have done to date)
5. Design Document (for implementers)
..
I think we've actually been spending quite a bit of time on #4 above, and
again, I'm not saying this is necessarily a bad thing -- We have sections
of the imaging model and requirements document that are titled "Design
Requirements", which should is probably not the right document for a section
of this name. However, we do need "Functional Requirements" section (or
document). This section would describe system behavior and any exceptions
or error conditions that might be encountered.
We actually "did" approach the cloud printing problem with use-cases in
mind, those being the standard (fundamental) imaging use-cases and behavior
that we've adopted from IPP and SM documents. And we also considered the
only major constraint (requirement) when coming up with the model..that
being that the system should work between complicated NAT/FW/routing
infrastructures and the public internet (cloud). So we did already come up
with a basic functional spec based on existing imaging use-cases and one
"new" requirement for cloud printing (FW/NAT compatibility).
To maximize our efficiency in getting this document done, I would recommend
that we change the name to:
"Cloud Imaging Model and Functional Specification" since we seem to already
know how the system is supposed to work (in some detail).
Comments ?
R.
On Jun 3, 2013, at 12:18 PM, Michael Sweet wrote:
> All,
>> I have posted the minutes from today's Cloud Imaging WG conference call
to:
>>>ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20130603> .pdf
>> Our next conference call is June 17, 2013 at 3pm ET.
>> There were no new action items.
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>
--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.
_______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.