My comments on whether to call the attribute that the submitter supplies in
the proposed FSG OpenPrinting WG papiPrinterQuery argument, "job-template"
or "job-context" or "processing":
There is one very important attribute, in fact the most important attribute,
that a papiPrinterQuery needs to be able to submit and that is
"document-format=xxx" in his query. It is the only attribute that IPP
allows the submitter to supply for its Get-Printer-Attributes operation in
order to constrain the supported results that the Printer returns. In IPP,
the "document-format" attribute is NOT a Job Template attribute, it is an
Operation attribute. The reason is that it is not subject to
"ipp-attribute-fidelity". The Printer MUST reject a job if the
"document-format" isn't a supported one, even if "ipp-attribute-fidelity" is
'false'. Otherwise, the Printer prints garbage for an unsupported document
format.
I see three options for papiPrinterQuery:
1. Add "document-format" as an additional input parameter to
papiPrinterQuery. Then rename "job-context-attrs" to "job-template-attrs",
since only Job Template attributes would be supplied there.
2. Rename "job-context-attrs" to "processing-attrs". The PWG Semantic Model
current version does include DocumentFormat as one of the Processing
attributes.
[Note: The PWG Semantic Model spells attribute names, but not keyword
values, as mixed case, hence DocumentFormat as opposed to IPP's
document-format.]
[Comment on the PWG Semantic Model: indicate in both the AttributeFidelity
and DocumentFormat Processing attributes in section 4.3 Document Attributes,
that AttributeFidelity does NOT apply to DocumentFormat.]
3. Leave "job-context-attrs" as it is and clarify that it includes any of
the IPP Job Template attributes and the IPP "document-format" Operation
attribute.
Currently, the PAPI spec is using the IPP terminology and attribute name
spelling, not the PWG terminology and attribute name spelling which is fine
and is as the PWG Semantic Model intends. So I prefer 1 or 3. Lets not mix
the terminology in PAPI between IPP and PWG Semantic Model. Also when the
PWG Semantic Model invents something new, such as the Document object, it is
the intent to write a detailed IPP extension specification to pickup the
semantics with IPP terminology and IPP attribute/operation spelling.
ISSUE for PWG Semantic Model and FSG PAPI spec:
When the Document object is added, do we need a separate context attribute
list to be supplied in the papiPrinterQuery function call, or can any
Document Template attributes be included in the same list?
Presumably there should be two IPP Printer Description attributes that
contain the names of the Job Template versus Document Template attributes:
"job-template-attributes-supported" and
"document-template-attributes-supported" since the lists are not the same.
For example, "job-priority" is only a Job Template attribute.
[PWG spelling and terminology would be: JobProcessingAttributesSupported and
DocumentProcessingAttributesSupported). Note: that this is one case where
the attribute names between IPP and PWG Semantic Model will differ in more
than spelling because of differing terminology.]
Tom
-----Original Message-----
From: Alan Hlava [mailto:hlava at us.ibm.com]
Sent: Thursday, August 22, 2002 10:03
To: printing-cap at freestandards.org
Subject: Re: [printing-cap] (no subject) [Capability Query addition to PAP
I]
On Thursday, 08/22/2002 at 12:55 AST, Michael Sweet <mike at easysw.com> wrote:
> We could use "job-context" instead of "job-template" as the prefix;
> I chose "job-template" just because that is the nomenclature that
> IPP uses...
Should PAPI then use the "job-template" terminology for the new
papiPrinterQuery argument?
Regards,
Alan Hlava
IBM Printing Systems Division
hlava at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/sm/attachments/20020826/58d7a39e/attachment-0001.html