Semantic Model Mail Archive: SM> Document Object Issues Reso

Semantic Model Mail Archive: SM> Document Object Issues Reso

SM> Document Object Issues Resolution

From: Zehler, Peter (
Date: Fri Oct 25 2002 - 14:08:16 EDT

  • Next message: Zehler, Peter: "SM> RE: IPP> "-actual" containment issue"

    Here are the resolutions to the Document Object issues that were reviewed at
    the Semantic Model Teleconference. Tom Hastings will be updating the
    document. Please send any corrections or additional issues to the Semantic
    Model and IPP mailing lists.
    Next week's telecon will review the "-actual" extension to IPP. See

    Here are the 18 issues (which are also highlighted in the spec) and the
    ISSUE 01: Need to add all new attributes to CIP4/PODi/FSG IPP mapping
    document. When?
    <PZ> The PWG Semantic Model and Schema are being updated with the Document
    Object and will track its evolution. We will wait until the Document Object
    is close to completion before bringing it to CIP4/PODi/FSG.<PZ/>
    ISSUE 02: Do we want to say which values of "multiple-document-handling" a
    Printer MUST support? The defined values are: 'single-document',
    'single-document-new-sheet', 'separate-documents-uncollated-copies', and
    <PZ> We will not mandate any specific "multiple-document-handling". We will
    leave it to implementations to declare which values they support. <PZ/>
    ISSUE 03: Are the 3 attributes: 'document-number', 'document-state', and
    'document-state-reasons' the right attributes to return when the client does
    not supply the "requested-attributes" operation attribute? Should we
    include the "document-id-uri" (uri) attribute that the Printer generates as
    <PZ> We will return the document equivalent of what is returned in
    ISSUE 04: OK that we don't have a way to set all documents in a single
    request? The Printer MUST reject the request with
    'client-error-bad-request', if the client does not supply the
    "document-number" operation attribute. There is no way to set all documents
    explicitly in a single request, since a failure would require the Printer to
    back out all changes in all documents. However, if the client sets the
    corresponding attribute at the Job Level using the Set-Job-Attributes
    operation, all documents in the job will be affected that don't have that
    attribute explicitly supplied at the Document Level.
    <PZ> We will not have a way to set attributes in all the documents in one
    request. <PZ/>
    ISSUE 05: OK, that Cancel-Document operation is OPTIONAL, while the
    Cancel-Job operation is REQUIRED by [RFC2911]?
    <PZ> The Cancel-Job operation will be mandatory. <PZ/>
     ISSUE 06: OK to have the "message" operation attribute supplied in the
    Cancel-Document operation be sent to the operator in some unspecified way,
    like Cancel-Job, which could include setting the Job's "message-to-operator"
    Job Template Job attribute or should we just do away with the "message"
    operation attribute in the Cancel-Document operation?
    <PZ> The Document operation attribute will be "document-message" in all
    cases and it will populate the "document-message" attribute of the Document
    Object. <PZ/>
    ISSUE 07: OK not to have a "document-message-from-operator" for use with
    Document operations, like with the Cancel-Current-Document operation that an
    operator is likely to use?
    <PZ> The Document operation attribute will be "document-message" in all
    cases and it will populate the "document-message" attribute of the Document
    Object. <PZ/>
    ISSUE 08: Should a Document's "document-state-reasons" keep a Job from
    being released with Release-Job? Or should there be no such reasons for the
    "document-state-reasons" Document Description attribute? For example, what
    about the 'resources-are-not-ready' value of the "document-state-reasons"
    Document Description attribute? Or maybe the 'resources-are-not-ready' is
    only for the "job-state-reasons" Job Description attribute. Then there
    would't be any "document-state-reasons" that affect job scheduling.
    <PZ> No value of "document-state-reason" will prevent the release of a Job.
    The "document-state-reason" value 'resources-are-not-ready' will be removed
    ISSUE 09: Shouldn't we have both a "job-mandatory-attributes" and a
    "document-management-attributes" operation attribute, one for use in Job
    Creation operations and the other for use in Document Creation operations?
    <PZ> Yes <PZ/>
    ISSUE 10: MUST Printer return document-id-uri? See Table 5
    <PZ> Yes <PZ/>

    ISSUE 11: MUST Printer support document-id-uri? See Table 5
    Table entry:
    document-id-uri uri MUST? ISSUE 10 MUST? ISSUE 11
    <PZ> Yes <PZ/>
    ISSUE 12: The "document-name" Document Description attribute is settable by
    Set-Document-Attributes (like "job-name")? But It's the only Document
    Description attribute that is marked (r/w)? Do we really need to be able to
    let a client change the "document-name" with the Set-Document-Attributes
    <PZ> Yes <PZ/>

    ISSUE 13: MUST Printer support document-id-uri as a Document Description
    <PZ> Yes (Note: The PWG Semantic Model has DocumentIdUri in
    JobStateElements) <PZ/>

    ISSUE 14 OK that we don't have job-message-from-operator as a Document
    object attribute?
    <PZ> Yes <PZ/>

    ISSUE 15: Can we get rid of 'resources-are-not-ready' for the
    document-state-reasons, since the Document object isn't scheduled?
    <PZ> Yes <PZ/>

    ISSUE 16: Should the "document-id-uri" Document Description attribute be
    REQUIRED for the Printer to support in any Document Creation operation, as a
    way of uniquely identifying a Document object across all Printers?
    <PZ> Yes <PZ/>
    ISSUE 17: Should we REQUIRE the Printer to accept a "document-id-uri" as an
    alternative way for clients to specify the target of Document object
    operations? I know that implementers have grumbled about the "job-uri"
    being REQUIRED for the Printer to support and accept as the target.
    <PZ> No <PZ/>

    ISSUE 18: Or should the client be REQUIRED to support some of the Document
    <PZ> No <PZ/>

                                    Peter Zehler
                                    Xerox Architecture Center
                                    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

    This archive was generated by hypermail 2b29 : Fri Oct 25 2002 - 14:08:37 EDT