For Get-Attributes and GetJobs of document attributes, such as document-name,
I was trying to keep things simple by saying that in a job with 2 or more
documents, the value of each such attribute is a set of the document values.
For example, if I submit a job with two documents whose document-name
attributes are "foo" and "bar", then Get-Attributes with document-name
requested shall return in protocol syntax
"document-name 3 foo 3 bar"
This is the syntax for a set of values for document-name.
This solution does not solve the problem of document-attributes that
are multi-valued, but we don't have any yet. So we can defer the solution.
Bob Herriot
> From hastings@cp10.es.xerox.com Thu Jun 19 11:31:30 1997
>
> At 16:53 06/18/97 PDT, Robert Herriot wrote:
> >I agree with Tom that we should delete "number-of-documents" because
> >we have added a new parameter to Send-Document called (I propose)
> >"last-document" which is Boolean.
>
> The problem with "last-document" as a name for the input-parameter,
> is that the corresponding job attribute would have to be different,
> say, "job-submission-complete". I think that as a principle, the
> names of the input parameters and the names of the job attributes
> that the input parameters set should be the same.
>
> Using the same names for input parameters as the corresponding job
> attributes (when there are both) will also make the encoding more
> understandable, since we don't have any separate buckets for input
> parameters in the encoding, but have just a single set of attribute
> representations as input parameters.
>
> Or were you prosing that we don't need a Boolean job attribute
> that indicates whether the job is complete or not? Since we have
> the "job-state-reasons" 'job-incoming' value, perhaps that is enough to indicate
> to a requester in a Get-Attrbutes request that the job is not yet
> complete? If we don't also need a "job-submission-complete" job attribute,
> then the input-parameter name "last-document" Boolean is fine.
> Not having the "job-submission-complete" job attribute makes it more
> mandatory that an implementation that supports Create-Job and Send-Document
> also support the 'job-incoming' reason in the "job-state-reasons" attribute.
>
>
> >
> >I don't agree with Tom's suggestion of to have a number-of-documents
> >that the Printer increments. I would rather allow the user to query
> >document-name and get back a set of n document names.
>
> I can agree that we don't really need a "number-of-documents" job
> attribute, since the requester can find the number of documents by
> requesting a document attribute, such as "document-name"
>
> But that brings up the need for a clarification of how the Get-Attributes
> operation returns document attributes.
>
> The Get-Attributes operation for document attributes needs a lot of
> clarification. Currently the model document has only 3 document attribtes:
> "document-name", "document-format", and "document-uri".
>
> I had thought that the document attributes would come back in groups,
> one group for each document if and only if the requester requests a
> document attribute, such as "document-name". I thought this, because the
> document has been made an object (but with no operations on it).
>
> Bob might be suggesting that the Printer returns a single multi-valued
> attribute "document-format", with a separate value for each document.
>
> If a requester supplies:
> Create-Job(...)
> Send-Document(
> "document-format" = 'application/postscript'
> "document-name" = 'Monthly Slides' )
> Send-Document(
> "document-format" = 'application/vnd.hp-PCL'
> "document-name" = 'Monthly Report'
>
> Get-Attributes with "requested-attributes" = 'document-format', 'document-name';
> input parameter would return:
>
> Result Attributes:
> "document-format" = 'application/postscript', 'application/vnd.hp-PCL'
> "document-name" = 'Monthly Slides', 'Monthly Report'
>
> I had assumed that the result would group document attributes with some
> specified document attribute as the indicator that the next set of
> document attributes were following. Either we pick "document-name"
> or make up a new read-only status attribute, say, "document-sequence-number"
> (as in DPA) that is set by the Printer. I prefer the latter:
>
> Result Attributes:
> "document-sequence-number" = '1'
> "document-format" = 'application/postscript'
> "document-name" = 'Monthly Slides'
> "document-sequence-number" = '2'
> "document-format" = 'application/vnd.hp-PCL'
> "document-name" = 'Monthly Report'
>
> Comments?
>
> Tom
>
>
>
>
> >
> >Bob Herriot
> >
> >Tom's proposal of adding
> >> From hastings@cp10.es.xerox.com Wed Jun 18 15:14:53 1997
> >
> >>
> >> At 01:04 06/18/97 PDT, Scott Isaacson wrote:
> >> >Randy,
> >> >
> >> >>>> Randy Turner <rturner@sharplabs.com> 06/12/97 06:10PM >>>
> >> >> In our current document we have a CREATE-JOB operation that specifies up
> >> >> front
> >> >> how many documents we have. Is this an unrealistic requirement for
> >> >> future IPP
> >> >> clients (or drivers) ? Will they always know how many documents are
> >> >>coming when
> >> >>they first do the CREATE-JOB?
> >> >
> >> >The model document shows this (number-of-documents) as an optional attribute
> >> >in
> >> >the Create. If it is there, it better be correct. If not, it is up to the
> >> >implementation
> >> >to handle as many Documents as might be thrown its way (I claim that it
> >> >might fail
> >> >after some N+1 documents). Why include it at all if it is optional? It
> >> >might help some
> >> >implementations with resource management.
> >>
> >> In order to avoid another error condition and a requirement for the
> >> server to check for the proper number of documents, lets delete the
> >> "number-of-documents" input parameter.
> >>
> >> However, we still need a read-only job attribute that the IPP server
> >> SHALL increment by 1 with each Send-Document operation.
> >>
> >> If we can't agree to delete the "number-of-documents" input parameter
> >> from Create-Job, then lets at least change the name to something like:
> >> "expected-number-of-documents", so that it is not confused with the
> >> read-only "number-of-documents" job status attribute which the IPP printer
> >> increments as each Send-Document is received. But I don't see the
> >> need for such an input-parameter. Lets wait to see if implementations
> >> find a need for such an input-parameter and it can be registered later.
> >>
> >> Ok?
> >>
> >> >
> >> >As other mail has indicated, we need a flag in the Send-Document
> >> >that says this is the last document.
> >>
> >> Also from the PRO disussion yesterday, a requester must be able to
> >> issue a Send-Document with no document data and just the flag set
> >> to TRUE, since the requester might not have know that it was the
> >> last document when the requester did the Send-Document with the data.
> >>
> >> This flag is both an input-parameter of the Send-Document operation
> >> that also sets the corresponding job attribute of the same name.
> >>
> >> Randy's protocol document had the input parameter named as an imperitive
> verb:
> >> "end-document-stream", but that isn't such a good name for the
> >> corresonding job attribute. How about the ISO DPA name:
> >> "job-submission-complete" for both the input parameter and the read-only
> >> job status attribute.
> >>
> >> Tom
> >>
> >> >
> >> >Scott
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>