While I was in favor of adding the "document-name" as an operational
attribute at the telecon yesterday, Carl-Uno and I have discovered
several problems and we have a simple solution.
The problems are:
1. Does Create-Job operation also allow a "document-name" operational
attribute? Then Create-Job continues to be the same as Print-Job,
except that no data can be supplied. Also the defaulting rules that
Bob wrote up can be applied by the Printer in Create-Job.
2. If the client doesn't/can't supply a "document-name" in the Create-Job
operation, the Printer doesn't want to wait for the first Add-Document
to get the "document-name" or "document-uri" attribute in order to default
the "job-name" attribute. Not returning a "job-name" on Create-Job
response seems a problem too (since it is MANDATORY to return it).
3. If we keep the semantics that the Printer defaults the "job-name" from
the "document-name" and "document-uri", I think that the "document-name"
should have more priority than "document-uri", since document-uri is
usually less user friendly and is sometimes algorithmically generated
(digits).
Rather than solving the above problems, Carl-Uno and I suggest the following:
1. Do NOT have a "document-name" operational attribute at all in any
operation (same as we agreed in Atlanta).
2. Since the "job-name" attribute is MANDATORY for a Printer to support,
lets also require that the client supply the "job-name" operational
attribute. Then we don't need any defaulting rules for the Printer
for the "job-name" attribute. It is up to the client to determine
the "job-name" either algorithmically from the (first) document content or
allowing the end-user to supply and to ALWAYS supply something in
Print-Job, Print-URI, and Create-Job.
Comments?
Tom
At 17:45 09/24/97 PDT, Robert Herriot wrote:
>Scott,
>>Here is some new wording for job-name initialization that relates to
>the discussion item from today's teleconference, as described in the
>minutes (see excerpt below).
>>The following change should be made to section 4.3.4, line 1625 of your
>9/3/97 document. I have changed a MAY to a SHOULD because I think that
>it more what we intended.
>>Existing sentence preceding the change:
>>If, however, it [the job-name] is not supplied by the client in the
>create request, the Printer, on creation of the Job SHALL generate a
>name.
>>New Sentence:
>>The printer SHOULD generate the value of the job-name from the
>first of the three following sources that produces a value: 1)
>"document-URI" of the first (or only) document, 2) "document-name" of
>the the first (or only) document, 3) some piece of Job specific
>information.
>>Removed Sentence:
>>The printer MAY choose to use the value of the "document-name" of the
>first (or only) document (or any piece of Job specific information) as
>a basis for generating a job name.
>>Additional comment
>>The description for "document-name" does not state whether it can be
>present when a "document-URI" is present, but my recollection is that
>we said it could be. That is, it is not necessarily the file name of
>the document.
>>>> From cmanros at cp10.es.xerox.com Wed Sep 24 16:24:50 1997
>>>>>> 1) Consequences of Atlanta proposal to take out document level attributes.
>>>> Of Bob Herriot's earlier listed 3 alternatives, alternative 2) seems to get
>> most support both from the DL and the participants in the call.
>>>> The general proposal for resolution include the following:
>> a) Keep the Print-URI and Send-URI operations.
>> b) The actual URIs are operational attributes. They are not stored on the
>> job object and cannot come back in a Get-Attributes operation.
>> c) Add back document-name as an operational attribute on Print-Job,
>> Print-URI, and Send-Document operation requests. It is not stored on the
>> job or document objects and cannot come back in a Get-Attributes operation.
>> d) Describe algorithm of how to populate job-name from first document-name
>> in the job, if not supplied by requestor.
>>>> Bob Herriot to write draft text and send to the DL.
>>>>>