IPP> RE: Dennis's good comments and issues with the Document Object sp ec

IPP> RE: Dennis's good comments and issues with the Document Object sp ec

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Jun 19 13:28:11 EDT 2003


Dennis,

My replies extracted for easier reading of your 3 comments:

10. About DMC ISSUE 07:
DMC ISSUE07: I definitely believe that we need a "Document-equivalent" of
job-collation-type.  

<dmc>
Maybe I'm not understanding.  Can't you specify the "copies" attribute at
the Document level?  Therefore, you could have a Job that was made up of 1
copy of Document 1, 3 copies of Document 2, and 1 copy of Document 3,
couldn't you?  If you did, you might want to know if the 3 copies of Doc2
were collated or uncollated.  I must be missing something--is there a
section that would straighten me out?
</dmc>
<th>
Now I see what you are suggesting.  I suppose for consistency we could have
a "collation-type" as a Document Template attribute.  As long as it is clear
that an implementation can implement the "job-collation-type" Job Template
attribute without having to do the "collation-type" Document Template
attribute (and vice versa).
</th>



15. about Editorial07:
<dmc>
Where did this concept of "saving a job" come from?
</dmc>
<th>
See "IPP: Production Printing Attributes - Set 2" which has an initial
version at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set2-draft-v0_1-020
821.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_PPE/pwg-ipp-prod-print-set2-draft-v0_1-020
821.pdf
Its useful for a production printer when you want to rip once and print at
many different times.
</th>


16. about Editorial08
DMC Editorial08 for Pete: This attribute's description, as well as the next
11 or so, have the name of the Job Description attribute added between the
"[rfc2911]" and the "$x.x".  

<th>
Sounds like we both agreeing to get rid of both repetitions of the attribute
name ("xxx") in these sections:

  "This OPTIONAL "xxx" Document Description attribute ..."

   (see [rfc2911] "xxx" ?4.3.10) 
</th>

Tom

-----Original Message-----
From: Dennis Carney [mailto:dcarney at us.ibm.com]
Sent: Tuesday, June 17, 2003 23:11
To: Hastings, Tom N
Cc: ipp at pwg.org
Subject: RE: Dennis's good comments and issues with the Document Object
sp ec






Tom,

Thanks for getting your comments in, in time for the f2f.  I had a few
responses, and I put them inline below, where I have liberally snipped to
get down to only those topics where I had a response.  My comments are
marked by <dmc></dmc>.

Dennis




 

                      "Hastings, Tom N"

                      <hastings at cp10.es        To:       Dennis
Carney/Boulder/IBM at IBMUS                                         
                      .xerox.com>              cc:       ipp at pwg.org

                                               Subject:  RE: Dennis's good
comments and issues with the Document Object sp       
                      06/17/2003 07:33          ec

                      PM

 

 





<snip>

10. About DMC ISSUE 07:
DMC ISSUE07: I definitely believe that we need a "Document-equivalent" of
job-collation-type.  It would have different semantics, since the Job level
semantics include the concept of documents, but I believe that since it is
useful to know whether a Job is doing collated or uncollated copies, it
would also be useful to know the same for Documents.

I disagree.  If we did add a Document attribute, it would need to have the
same value as at the Job Level, since you can't collate some documents and
not collate other documents in the same job.  We don't duplicate on the
Document object other Job level attributes that apply to the job as a
whole,
such as "job-name", "job-hold", "job-priority", "job-finishing".
<dmc>
Maybe I'm not understanding.  Can't you specify the "copies" attribute at
the Document level?  Therefore, you could have a Job that was made up of 1
copy of Document 1, 3 copies of Document 2, and 1 copy of Document 3,
couldn't you?  If you did, you might want to know if the 3 copies of Doc2
were collated or uncollated.  I must be missing something--is there a
section that would straighten me out?
</dmc>

<snip>

15. about Editorial07:
'completed-successfully' :  The Document completed successfully. There were
no warnings or errors in printing.  This value SHOULD be supported.
[rfc2911] ?4.3.8

'completed-with-warnings' :  The print part of the Document completed with
warnings (whether or not there were save errors).  This value SHOULD be
supported if the implementation detects warnings.  [rfc2911] ?4.3.8  DMC
Editorial07: What are "save errors"?  Why does this reason and the next
reason use the words "The print part of" when the previous reason doesn't?

'completed-with-errors' :  The print part of the Document completed with
errors (and possibly warnings too) (whether or not there were save errors).
This value SHOULD be supported if the implementation detects errors.
[rfc2911] ?4.3.8

When saving a job, the Job is really two parts: the print part and the save
part.  With 'completed-successfully' both parts are successful.  Sounds
like
this description could be improved.  How about adding to
'completed-successfully' "(or saving)" at the end of the second sentence?
<dmc>
Where did this concept of "saving a job" come from?
</dmc>

16. about Editorial08
DMC Editorial08 for Pete: This attribute's description, as well as the next
11 or so, have the name of the Job Description attribute added between the
"[rfc2911]" and the "$x.x".  This is not done anywhere else in this
document, and should be gotten rid of, I believe.  If it makes sense here,
we have to look at everywhere else it might make sense.

I agree it probably makes sense to remove the name of the attribute and
just
say "This OPTIONAL Document Description attribute ...", since the sentence
comes right after the heading.
<dmc>
I wasn't complaining about the attribute name at the start of the paragraph
(I admit I was tempted to, but successfully resisted :-), but instead about
the attribute name between the reference and the section number.  </dmc>




More information about the Ipp mailing list