Semantic Model Mail Archive: RE: SM> My response to some of

RE: SM> My response to some of the 18 Document issues...Comments?

From: McCarthy, Ann L (AMcCarthy@crt.xerox.com)
Date: Tue Mar 18 2003 - 13:09:13 EST

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

    All,

    WRT 12: recommend "ISO nnnnn.n-2001" as in JDF.

    --------------------------------------------------------------------
    Ann L. McCarthy
    XIG/SSTC Imaging Systems Architect
    Internal:8*221-8701 External: 585-231-8701
    FAX: 585-265-8871 Mailcode: B128-30E

    -----Original Message-----
    From: Zehler, Peter [mailto:PZehler@crt.xerox.com]
    Sent: Tuesday, March 18, 2003 9:52 AM
    To: Hastings, Tom N; sm@pwg.org
    Subject: SM> 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>

    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>

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

    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>

    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>

    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</>

    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>

    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>

    ISSUE 08: Are the conformance requirements for the
    "document-container-summary" attributes OK?
    <PZ>No opinion</>

    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?

    ISSUE 10: OK that "document-format-version" is REQUIRED for a Printer to
    support?
    <PZ>Yes</>

    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.

    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</>

    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>

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

    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</>

    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</>

    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</>

    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 : Tue Mar 18 2003 - 13:09:19 EST