Hastings, Tom N wrote:
> ...
> ISSUE 1a: Do we need formal definitions of each Operation or is the
> comparison with Job operations in Table 2 sufficient?
I think we should, even if you just cut-n-paste and rename things
to do it.
> ISSUE 1b: Should Print-Job and Print-URI also be called Document Creation
> operations since they create one Document object? The answer probably
> depends on the answer to the following issue:
Yes.
> ISSUE 1c: We're adding a Document Attribute group (tag) to Send-Document
> and Send-URI so that a client can supply Document Template attributes. OK
> that we don't add this group to Print-Job and Print-URI? The problem with
> adding the Document Template attribute group to Print-Job and Print-URI
> requests is that there becomes two ways for a client to supply many of the
> Job Template attributes that are Document Processing attributes, such as
> "media", "number-up", etc., Those two ways in a Print-Job or Print-URI are
> (1) in the Job Template attribute group or (2) in the Document Template
> attribute group. The PWG Semantic Model is defining each Processing
> attribute to be either a Job Processing attribute or a Document Processing
> attribute, but not both, so that there will only be one way to submit each
> Processing attribute in a PrintJob operation according to whether it is
> defined to be a Job Processing Attribute or a Document Processing Attribute.
> But for backward compatibility, IPP's Job Template attributes are a mixture
> of Job and Document Processing attributes, i.e., "job-priority" and
> "job-hold-until" versus "media" and "number-up" are passed mixed together in
> the Job Template attribute group.
WRT document vs. job template attributes, if we allow both groups
then it could be said that the job-sheets page(s) associated with
the job would use the job template attributes alone, while the
document file itself would use the document attributes as well as
the job template attributes. This would be consistent with
PWG5100.3's handling of the job-sheets-col attribute...
> ISSUE 1d: Agree that the Cancel-Current-Document, Delete-Document, and
> Set-Document-Attributes operations are OPTIONAL and that the
> Cancel-Document, Get-Document-Attributes, Get-Documents, and
> Validate-Document operations are REQUIRED as indicated in Table 2 when
> supporting the Document object?
Yes
> ISSUE 1e: Currently the returns operation attributes are the same for Job
> Creation and Document Creation responses. Should the "document-number" be
> added as an additional OPTIONAL response attribute to the Document Creation
> responses?
Yes.
> ISSUE 02: What do we want to do with the "document-overrides" collection
> attributes when supporting the Document object, which is no longer needed as
> either a Job Template, Document Template, or operation attribute in Document
> Creation requests? Not completely true, since the "document-copies" member
> attribute of the "document-overrides" attribute allows the client to supply
> different attributes to different copies of a document. Has anyone
> implemented Document Overrides?
I agree with Peter on this one - document-overrides doesn't serve
much purpose on a server that supports document objects. It might
be useful to allow either mechanism to be used (new/old clients),
but to disallow the use of both simultaneously.
> ...
> ISSUE 03: What do we want to do with the "page-overrides" collection
> attributes when supporting the Document object, which is still needed as a
> Job Template and Document Template attribute for overriding attributes in
> specified page ranges, but is not needed as an operation attribute on
> Document Creation requests?
I'd say continue to support page-overrides as either a job or
document template attribute, but not both (doing job-wide overrides
is tough enough already when dealing with multiple files - no need
to make life harder...)
> ISSUE 04: Is this query behavior of not appearing to copying down supplied
> Job attributes to the Document object and not bubbling up supplied Document
> attributes to the Job object OK?
I would say yes, since otherwise a client would not know which
attributes come from which object.
> ISSUE 05: Should we sort the attributes ignoring the [job-]? Currently the
> "job-" is used in the sort for attributes.
As far as the table in the spec, sort by name without the job-
prefix if you are dropping it, and add a note indicating that they
correspond to the similarly named attributes in the job object.
> ISSUE 06: How will we register these attributes with IANA, since they will
> be registered for IPP use, with the "job-" prefix. Do we add the ones
> without "job-" as aliases to the IANA registry as is done for charset
> registrations?
You could make them aliases, but in reality they represent different
things - the job-xyz attributes represent the job object as a whole,
while the xyz attributes (no job- prefix) represent the document
object.
Another option is to add "document-" as the prefix; this might
be appropriate for some of the keywords (document-state-reasons)
as well.
> ISSUE 07: Should we sort the attributes values including the [job-]?
> Currently the "job-" is ignored in the sort for attribute values.
See #5
> ISSUE 08: How will we register these attribute values with IANA, since they
> will be registered for IPP use, with the "job-" prefix. Do we add the ones
> without "job-" as aliases to the IANA registry for as is done for charset
> registrations?
See #6
> ISSUE 09: What other Printer Description attributes are needed, if any?
WRT the document object spec, I don't think there are any short of
a "multiple-document-jobs-limit" attribute specifying the maximum
number of documents per job, and I'm not sure that it is needed...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com