Semantic Model Mail Archive: SM> RE: [printing-cap] (no subj

Semantic Model Mail Archive: SM> RE: [printing-cap] (no subj

SM> RE: [printing-cap] (no subject) [Capability Query addition to PAP I]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Mon Aug 26 2002 - 13:35:00 EDT

  • Next message: Hastings, Tom N: "SM> Terminology comment: "Job Attributes" and "Document Attributes""

    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@us.ibm.com]
    Sent: Thursday, August 22, 2002 10:03
    To: printing-cap@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@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@us.ibm.com



    This archive was generated by hypermail 2b29 : Mon Aug 26 2002 - 13:36:21 EDT