Semantic Model Mail Archive: SM> Document object, Meeting No

SM> Document object, Meeting Notes, Thursday, March 20, 2003

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Mar 20 2003 - 18:49:59 EST

  • Next message: Hastings, Tom N: "SM> Updated Comparison of JDF FileSpec and corresponding IPP Document object available"

    Document object, Meeting Notes, Thursday, March 20, 2003
    File: document-object-meeting-notes-20030320.doc

    Attendees: Peter Zehler, Dennis Carney, Gail Songer, Ira McDonald, Bob
    Tailor, Tom Hastings, Harry Lewis.

    The notes are edited into Peter's response to the outstanding issues.

    We resolved all of the issues on the telecon. See the notes below.

    Please send any comments on these minutes now, so I can reflect in the
    updated document.

    [Editor's note: we changed the semantics of the "document-format-details"
    operation attribute at the end of the telecon from the member attributes
    being Must Honor to being Best Effort, but didn't revisit the name of the
    corresponding "document-format-details-allowed" (1setOf collection) Printer
    attribute. Since the Printer will allow other attributes and values (and
    ignore them), the "-allowed" suffix is now mis-leading. So Ira and I
    suggest that we change the suffix from "-allowed" to "-implemented". So
    change "document-format-details-allowed" to
    "document-format-details-implemented". OK? I've assumed this change in the
    following notes.]

    ACTION ITEM (Tom): Update and post the spec today or tomorrow.
    ACTION ITEM (Pete): Update and post the Semantic Model to reflect the
    agreements (probably Monday).

    Hold a second one hour review, next Thursday, March 27, 2003, same time
    (10:00 AM PST, 1:00 PM EST). Peter and Bob to setup the teleconference and
    webex, respectively.

    Tom

    From: Zehler, Peter
    Sent: Tuesday, March 18, 2003 06:52
    To: Hastings, Tom N; sm@pwg.org
    Subject: My response to some of the 18 Document issues...Comments?

    All,

    I saw many of the issues as "low hanging fruit". I have my responses to
    issue 0-7,10,13 inline below. Issues 8 and 12 I have no strong opinion on
    and issues 14 to 17 are basically work to be done. This leaves issues 9 and
    11. These involve how to represent the supported values for the document
    format detail attributes. I think we will need to dedicate a large chunk of
    time for this issue in Thursday's teleconference.

    Are there any comments on these issues or my responses?

    Pete

    ISSUE 00: Or should we just delete "input-document-number" operation
    attribute when we republish pwg5100.4 without "document-overrides?
    <PZ>Delete "input-document-number". Document numbers start at 1 and
    monotonically increment as documents are added to the Job.</PZ>
    AGREED.

    ISSUE 01: OK: OK to rename Send-Data to Send-Document-Data to reflect the
    object on which it operates?
    <PZ>No, keep it Send-Data. I see no reason for the longer name. The only
    data we send is associated with a Document. We don't have
    CreateJob-Document
    or Create-Printer-Job.</PZ>
    AGREED: to keep name as Send-Data

    ISSUE 02: OK to add Close-Job operation and to REQUIRE a Printer to support
    it, since PSI is using it?
    <PZ>Yes</>
    AGREED.

    ISSUE 03: Should we make "job-mandatory-attributes" a REQUIRED attribute
    for a Printer to support (if it supports the Document object)? Otherwise,
    clients won't support it and will be stuck with the "ipp-attribute-fidelity"
    attribute?
    <PZ>It should be an OPTIONAL Operation Attribute that a Printer MUST support
    if the Printer supports the Document Object.</PZ>
    AGREED: The Printer MUST support the "job-mandatory-attributes" operation
    attribute, client MAY supply.

    ISSUE 04: The "document-overrides" attribute is also useful in combination
    with the "pages-per-subset" attribute (see [pwg5100.4]) which divides up the
    Input Page stream concatenated across the Input Documents into separate
    Output Documents. For example, making every 10 Input Pages be a separate
    Output Document but the client only wants to staple the first Output
    Document. ISSUE 04: But what about Subset Finishing? Can we it be done
    without "document-overrides"?
    <PZ>Get rid of "document-overrides" in favor of the Document. Place the
    burden of the example corner case on the Client. The results can be easily
    achieved through the use of Documents and page-overrides.</PZ>
    AGREED: Subset finishing is how to staple ranges of pages that cover all of
    a single document? Do subset finishing with "page-overrides", instead of
    "document-overrides" (which is being deleted). One possibility is to use
    "pages-per-subset" (1setOf integer) as one of the member attributes of the
    "page-overrides" since "pages-per-subset" is a Job Template attribute that
    applies to an Input Document. Tom to talk to Claudia Alimpich from IBM as
    well, since the concept of subset finishing is also in the FSG Job Ticket
    API.

    ISSUE 05: OK that when a Printer supports Page Overrides, that we REQUIRE
    the Printer to continue to support the "page-overrides" as an operation
    attribute in Send-Document and Send-URI as well as a Document Template
    attribute?
    <PZ>Yes</>
    AGREED: If a Printer supports "page-overrides":

    a. the Printer MUST support both the "page-overrides" as (1) an operation
    attribute (for backward compatibility and clients that don't support the
    Document object) and (2) as a Document Template attribute in Send-Document
    and Send-URI requests. The client MAY supply "page-overrides" as either a
    Job Template attribute or an operation attribute in Send-Document and
    Send-URI requests.

    b. the Printer MUST support "page-overrides" as a Document Template
    attribute, not as an operation attribute in Create-Document requests.

    ISSUE 06: OK that "document-container-summary" is only one level deep?
    <PZ>Yes, this information is not a manifest of the contained documents.
    It is used to determine if a Printer can process the Document. Clients
    are free to send individual compressed Documents if a manifest of a Job's
    contents is required.</PZ>
    AGREED: That is it OK to have only one level for the summary details
    attribute that the Printer uses to accept or reject jobs.

    6.1 Should have two separate attributes, one for summary details and one for
    a "document-manifest" which has a separate entry for each file in a
    container and needs to allow nesting to be expressed.
    ACTION (Tom and Bob): Advocate two separate attributes with CIP4, rather
    than defining one form that tries to do both.

    6.2 We'll won't add the manifest attribute to IPP Document object at this
    point.

    6.3 Need a better word than container and a better word than summary.
    Agreed to go back to "document-format-details" and clarify that it is
    unordered and applies to a single document file as well as a container file
    containing multiple files.

    6.4 Move the top level operation/Document Description attributes (except
    "document-format" which remains at both levels) back to be member attributes
    of the "document-format-details" collection operation/Document Description
    attribute. So the following Document Description attributes will be the
    member attributes of the "document-format-details" operation/Document
    Description attribute:

      document-creator-application-name (name(MAX))
      document-creator-application-version (text(127))
      document-creator-os-name (name(40))
      document-creator-os-version (text(40))
      document-format (mimeMediaType
      document-format-device-id (text(127))
      document-format-version (text(127)
      document-natural-language (naturalLanguage)

    6.5 Allow, but don't require, the client to supply one of the collection
    values to describe the details about the top level container format
    (application/zip and multipart/related) as well.

    6.6 Add a "document-format-details-detected" Job Description attribute which
    the Printer MAY support and fill in with detected values. Keep
    "document-format-detected" as a separate Job Description attribute, so that
    collections aren't required by a Printer that only wants to reflect the
    document format detected.

    6.7 The "document-format-details" will remain an operation attribute that
    the Printer MUST copy to the corresponding Document Description attribute,
    same as for the "document-format" operation/Document Description attribute.

    6.8 Other Document Description attributes that the Printer detects/updates,
    such as "k-octets", are a separate concept and aren't to be added to
    "document-format-details" or "document-format-details-detected".

    ISSUE 07: Is the description of "document-container-summary" attribute OK?
    <PZ>Clarify that a manifest can be accomplished by the Client sending
    individually compressed Documents.</PZ>
    AGREED.

    ISSUE 08: Are the conformance requirements for the
    "document-container-summary" attributes OK?
    <PZ>No opinion</>
    AGREED: A Printer MUST support the "document-format" and the
    "document-format-version" member attributes, and MAY support any of the
    other member attributes:
      document-creator-application-name (name(MAX))
      document-creator-application-version (text(127))
      document-creator-os-name (name(40))
      document-creator-os-version (text(40))
      document-format-device-id (text(127))
      document-natural-language (naturalLanguage)

    ISSUE: 09: How can a Printer indicate which combinations of
    document-creator-application-name (name(MAX)),
    document-creator-application-version (text(127)), document-creator-os-name
    (name(40)), document-creator-os-version (text(40)),
    document-format-device-id (text(127)), document-format-version (text(127),
    document-format (mimeMediaType) and "document-natural-language
    (naturalLanguage) are supported?
    AGREED:
    9.1 Add a "document-format-details-supported" (1setOf type2 keyword) Printer
    Description attribute which lists the member attributes of
    "document-format-details" that the Printer supports. Values:
    document-creator-application-name, document-creator-application-version,
    document-creator-os-name, document-creator-os-version, document-format,
    document-format-device-id, document-format-version, and
    document-natural-language.

    9.2 We won't define "xxx-supported" attributes that go with each of the
    member attributes of "document-format-details", since the member attributes
    are not orthogonal to each other. Instead, define a
    "document-format-details-implemented" (1setOf collection) Printer
    Description attribute whose member attributes show collections of values
    that go together.

    The member attributes of "document-format-details-implemented" are:
      document-creator-application-name-implemented (1setOf name(MAX))
      document-creator-application-version-implemented (1setOf text(127))
      document-creator-os-name-implemented (1setOf name(40))
      document-creator-os-version-implemented (1setOf text(40))
      document-format-implemented (1setOf mimeMediaType
      document-format-device-id-implemented (1setOf text(127))
      document-format-version-implemented (1setOf text(127)
      document-natural-language-implemented (1setOf naturalLanguage)

    9.3 Except for "document-format", all other member attributes supplied by a
    client are supplied as "hints", that is Best Effort (i.e., treat as if
    fidelity is false), whether the Printer's
    "document-format-details-implemented" Printer Description attribute has that
    member attribute or not and whether or not the Printer's
    "document-format-details-supported" has that keyword for that member
    attribute. The "document-format" operation attribute and member attribute
    of "document-format-details" remain as a Must Honor attribute (i.e., treat
    as if fidelity is true and reject the job if the document-format isn't
    supported).

    9.4 Currently, "ipp-attribute-fidelity" and the new
    "job-mandatory-attributes" do NOT apply to operation attributes, only to Job
    Template attributes. However as an exception, "ipp-attribute-fidelity" and
    the new "job-mandatory-attributes" will be defined to apply to the
    "document-format-details" operation attribute and all its member attributes.
    For example, the client can supply the following keyword value for the
    "job-mandatory-attributes" attribute:
    'document-format-details.document-format-os-name' indicating that the
    Printer MUST honor the OS name or MUST reject the job. The
    "document-format" member attribute (and operation attribute) will remain
    forever mandatory (Must Honor) as in [RFC2911], independent of
    "ipp-attribute-fidelity" and "job-mandatory-attributes".

    Example of a single set of values for a Printer of
    "document-format-details-implemented" (1setOf collection):

    {{document-format=application/ps, document-format-version=1, 2, 3},
     {document-format=application/ps, document-format-version=3,
        document-natural-language=en, fr, de},
     {document-format=application/vnd.hp-PCL, document-format-version=5e},
     {document-format=application/msword, document-format-version=5.0, 6.0,
    2000,
        document-format-os-name=MACOS, WINDOWS}
    }

    Typically, there will only be one value for "document-format" in each
    collection. However, there can be more than one occurrence of a collection
    value with the same "document-format". See above example which has two
    PostScript collection values.

    ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to
    support?
    <PZ>Yes</>
    AGREED: Printer MUST support the "document-format" and
    "document-format-version" member attributes if it supports the
    "document-format-details" collection attribute. The Printer MAY support
    additional member attributes.

    ISSUE: 11: The problem with separating "document-format" and
    "document-format-version" is how can a Printer describe what versions are
    supported, since the versions have to be associated with the document
    format.
    AGREED: The "document-format-details-implemented" (1setOf collection)
    Printer Description attribute describes which versions go with each document
    format. See ISSUE

    ISSUE 12: 'PDF/X-1:2001': From the ISO standard that specifies PDF/X.
    ISSUE 12: Or should the official ISO standard number, part number and date,
    be used instead, e.g., "ISO nnnnn.n-2001"?
    <PZ>No opinion</>
    AGREED: Use examples as agreed in CIP4 from the ISO standard itself, such
    as 'PDF/X-1:2001' and 'PDF/X-1a:2001' which are from the same ISO standard.

    ISSUE 13: The definition of "document-natural-language" in [rfc2911]
    §3.2.1.1 and [pwg5100.4] §5.1.7 is single-valued. OK that this Document
    Description attribute isn't 1setOf? Or should we extend
    "document-natural-language" to 1setOf naturalLanguage) and keep the same
    name? Or change the name to "document-natural-languages"?
    <PZ>Keep single-valued. It will handle the vast majority of cases and
    keep things simple</PZ>
    AGREED: Clarify that the first language in the document is used as the
    value.

    ISSUE 14: TBD - Need to add the "xxx-default" and "xxx-supported" to Table
    14 that go with the Document Template attributes.
    <PZ>OK</>
    AGREED

    ISSUE 15: TBD - Need to add the xxx-default and xxx-supported for each xxx
    in the IANA Registration of Document Template attributes.
    <PZ>OK</>
    AGREED

    ISSUE 16: TBD - Need to add the xxx-default and xxx-supported for each xxx
    in the IANA Registration of Job Template attributes being defined.
    <PZ>OK</>
    AGREED

    ISSUE 17: TBD - Need to list the keyword attribute values in the IANA
    Registration section. Do so by reference to the values registered for
    corresponding attributes.
    <PZ>OK</>
    AGREED

    Pete

                                    Peter Zehler
                                    XEROX
                                    Xerox Architecture Center
                                    Email: PZehler@crt.xerox.com
                                    Voice: (585) 265-8755
                                    FAX: (585) 265-8871
                                    US Mail: Peter Zehler
                                                    Xerox Corp.
                                                    800 Phillips Rd.
                                                    M/S 128-30E
                                                    Webster NY, 14580-9701

    <snip>
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/wd-ippdoc10-20030314.pdf
    <snip>
    Send any comments to the SM mailing list.

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Thu Mar 20 2003 - 18:50:26 EST