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

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

SM> RE: My response to some of the 18 Document issues...Comments? [IS SUE 03 "job-mandatory-attributes" = REQUIRED]

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Mar 18 2003 - 14:33:59 EST

  • Next message: Hastings, Tom N: "RE: SM> Summary of additions to JDF/FileSpec and IPP Document obj ect for document format versions"

    I agree with Peter's suggested resolutions to ISSUE 03, but need to test our
    understanding of the terminology, since I think that the spec needs to say
    that "job-mandatory-attributes" is a REQUIRED attribute in the Document
    Object spec, not OPTIONAL, in order to agree with Peter's suggestion.

    Peter wrote:

    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>

    When we say anything is "REQUIRED" in the Document Object spec, we mean it
    is REQUIRED if the Printer conforms to the Document Object specification,
    i.e., supports the Document Object. [This semantic for the word REQUIRED is
    true for any IPP extension specification].

    Here is what the Document Object spec says in the Conformance Terminology
    section to try to make the scope of the term "REQUIRED" clear:

    2.1 Conformance Terminology

    Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
    MAY, NEED NOT, and OPTIONAL, have special meaning relating to conformance as
    defined in RFC 2119 [rfc2119] and [rfc2911] section 12.1. If an
    implementation supports the extension defined in this document, then these
    terms apply; otherwise, they do not. These terms define conformance to this
    document (and [rfc2911]) only; they do not affect conformance to other
    documents, unless explicitly stated otherwise. To be more specific:

    REQUIRED - an adjective used to indicate that a conforming IPP Printer
    implementation MUST support the indicated operation, object, attribute,
    attribute value, status code, or out-of-band value in requests and
    responses. See [rfc2911] "Appendix A - Terminology for a definition of
    "support". Since support of this entire Document Object specification is
    OPTIONAL for conformance to IPP/1.1, the use of the term REQUIRED in this
    document means "REQUIRED if this OPTIONAL Document Object specification is
    implemented".

    RECOMMENDED - an adjective used to indicate that a conforming IPP Printer
    implementation is recommended to support the indicated operation, object,
    attribute, attribute value, status code, or out-of-band value in requests
    and responses. Since support of this entire Document Object specification
    is OPTIONAL for conformance to IPP/1.1, the use of the term RECOMMENDED in
    this document means "RECOMMENDED if this OPTIONAL Document Object
    specification is implemented".

    OPTIONAL - an adjective used to indicate that a conforming IPP Printer
    implementation MAY, but is NOT REQUIRED to, support the indicated operation,
    object, attribute, attribute value, status code, or out-of-band value in
    requests and responses.

    It has been suggested (and I put in the proposed PWG Template) that it is
    not good to repeat the definitions of terms that appear in other
    specifications, since the definition may inadvertantly be changed. Also we
    don't need to use the term "NEED NOT" which [rfc2911] introduces and
    explains in section 12.1. So I'll recast the 5 uses of NEED NOT to be MAY
    in the next version.

    So how about this much shorter explanation for the Document Object section
    2.1 Conformance Terminology:

    Capitalized terms, such as MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
    MAY, and OPTIONAL, have special meaning relating to conformance as defined
    in RFC 2119 [rfc2119]. If an implementation supports the extension defined
    in this document, then these terms apply; otherwise, they do not. These
    terms define conformance to this document (and [rfc2911]) only; they do not
    affect conformance to other documents, unless explicitly stated otherwise.
    For example, the term REQUIRED in this document means "REQUIRED if this
    OPTIONAL Document Object specification is implemented".

    Comments?
    Tom

    -----Original Message-----
    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>

    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 - 14:34:13 EST