You are not considering the other advantages of the 'CreateJob'
operation. The 'Validate' option only validates a set of
attributes against what a particular object supports. It
has no relationship to a job. Meaning that just because
you send a 'Validate' request, does not necessarily mean
that a print job is next in the sequence.
RKD> No, but it might be.
The 'CreateJob' not only validates attributes but also
determines whether or not resources can be applied NOW
to processing a job with these requirements.
RKD> This must mean that upon receiving a CreateJob, the
RKD> Printer promises to maintain the state it was in with
RKD> respect to requested resources until the print job
RKD> is complete. Is this agreed?
RKD> Does a client send CreateJob, assuming that if resources are
RKD> not ready that the Printer will schedule the job accordingly,
RKD> i.e. schedule all jobs waiting for A4 paper to print when A4
RKD> paper is loaded, or does a client keep "pinging" the Printer
RKD> with CreateJobs until it finds the resources are ready, then
RKD> consummates the print job by sending the data?
RKD> If we believe that the first is the preferred method for
RKD> handling jobs waiting for resources then I claim that just
RKD> using the PrintJob operation works as well as CreateJob and
RKD> SendDocument since I don't care if the resources are actually
RKD> ready NOW or not (and I doubt that I want to keep "pinging"
RKD> the Printer to find out).
Also, 'CreateJob'
returns the URI for the job object created immediately so you have some
way to either do a 'GetAttributes'
or a 'Cancel' on the job if either one of these operations is required.
RKD> Doesn't PrintJob return a URI? If not why doesn't it?
If you're looking to delete operations, 'Validate' would go before
'CreateJob' IMHO.