Semantic Model Mail Archive: RE: SM> Summary of additions to

RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions

From: HALL,DAVID (HP-Vancouver,ex1) (dhall@hp.com)
Date: Mon Mar 17 2003 - 13:55:23 EST

  • Next message: Hastings, Tom N: "SM> IPP Document object specification, March 14 2003 version, is avai lable for SM 3/20 telecon"

    Having just implemented an initial PSI TargetDeviceSupportInterface, another
    IPP attribute appears to be very important:

    PrinterMakeAndModel

    While the DeviceID can be utilized to indirectly determine the appropriate
    device data format, it is much more convient to utilize the printer make and
    model, if it corresponds to the Printer Driver Name.

    I would like to recommend that we consider this attribute for inclusion in
    the below list..

    Dave

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Friday, March 14, 2003 6:00 PM
    To: CIP4 Capabilities WG [capabilities@cip4.org]
    Cc: sm@pwg.org
    Subject: SM> Summary of additions to JDF/FileSpec and IPP Document
    object for document format versions

    We've had a long thread of discussion about the need to indicate the version
    of a document format in a job submission along with its MIME type in JDF and
    IPP. In JDF this infomation is represented as attributes in the FileSpec
    resource. In IPP, the PWG Semantic Model (SM) and the Print Service
    Interface (PSI), the document format and versions are represented as
    Document Description attributes. In IPP the client submits these as
    operation attributes which the Printer copies to the corresponding Document
    Description attributes.

    Here is a quick summary to see if we are in agreement:

    1. Don't add stuff to the IPP Document object that hasn't been asked for,
    even though its being added to JDF FileSpec resource. So IPP will remain a
    subset of JDF. So while adding TransferEncoding (per Israel Viente's
    request), DocumentClass (to help distinguish fonts from other files), and
    some attribute for use with fonts to designate which organization they are
    coming from (which need work) so we don't need MIME types for fonts.

    2. The following list show the relationship between IPP Document object and
    the JDF FileSpec. In JDF, only ContainerSummary, IEEE1284DeviceID and
    FileFormatVersion are new. All of the IPP Document attributes are new
    except for document-format and document-natural-language:

    document-container-summary (collection) ContainerSummary
      which can contain:
      document-creator-application-name (name(MAX))
      document-creator-application-version (name(MAX))
      document-creator-os-name (name(MAX))
      document-creator-os-version (name(MAX))
      document-format (mimeMediaType)
      document-format-device-id (text(127))
      document-format-version (text(127)
      document-natural-language (naturalLanguage)
    document-creator-application-name (name(MAX)) Application
    document-creator-application-version (name(MAX)) AppVersion
    document-creator-os-name (name(40)) AppOS
    document-creator-os-version (name(40)) OSVersion
    document-format (mimeMediaType) MimeType
    document-format-detected (mimeMediaType) N/A
    document-format-device-id (text(127)) IEEE1284DeviceId
    document-format-version (text(127) FileFormatVersion
    document-natural-language (naturalLanguage)

    I'll have an updated spec for IPP Document object out by Monday AM and a
    corresponding FileSpec on Monday.

    I won't be addressing additional MIME types in these documents. That is
    separate.

    Tom

    This archive was generated by hypermail 2b29 : Mon Mar 17 2003 - 13:55:33 EST