IPP Mail Archive: IPP> Semantic Model Telecon - Document Obj

IPP Mail Archive: IPP> Semantic Model Telecon - Document Obj

IPP> Semantic Model Telecon - Document Object Review

From: Zehler, Peter (PZehler@crt.xerox.com)
Date: Wed Oct 23 2002 - 09:08:26 EDT

  • Next message: Michael Sweet: "Re: IPP> First draft IPP standard for Color and Imaging Attributes availab le"


    This Thursday at 1pm EDT is the Semantic Model teleconference. The
    teleconference is one hour long. It will be run using both phone and Webex.
    Anyone that does not yet have Webex installed should do that before
    Thursday. Information for the phone and Webex are included below.

    This week's teleconference will focus on the Document Object proposal for

    The agenda for the teleconference:
    1) General Semantic Model and schema status
    2) Review Document Object specification.
    3) Next steps


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

    PS to Bob Taylor: Let me know if there is any problem with Webex for this

    Dial in Info:
    Phone Number: (877) 776-6306
    (Phone Number for Xerox Employees: 8*594-0576)
    webex info:
    We will also use an on line tool called webex,
    if you have not used this before, setup up by
    following the First Time Users instructions.
    Do this in advance of the meeting.

    For fully interactive meetings, including the ability
    to present your documents and applications, a one-time
    setup takes less than 10 minutes. Click this URL to set up now:


    Then click New User.

    On Thursday use:

    Then click join unlisted meeting.
    Use the info below:
    Name: PWG Semantic Model
    Date: 10/24/2002
    Time: 1:00PM, (GMT -04:00) Eastern Time, USA & Canada (Daylight Time)
             10:00AM, (GMT -07:00) Pacific Time, USA & Canada (Daylight Time)
    Meeting Number: 21366675
    Meeting Password: pwg_sm
    Bob Taylor (HP)
    Tom Hasting's information on the document:

    I've down loaded version 0.4 of the IPP Document object spec. Its now 76
    pages long. We resolved the 15 issues, but there are now 18 smaller ones
    (see below). Peter would like to put review of this on the Semantic Model
    telecon agenda for Thursday, October 24, 1-2 PM EDT (10-11 AM PDT).
    Note: The IPP-Document-Object.pdf will be used for the review (v0.04)


    Here is the Abstract:

    Abstract: This IPP specification extends the IPP Model and Semantics
    [RFC2911] object model by defining a Document object. The [RFC2911] Job
    object is extended to contain one or more Document objects which are passive
    objects operated on by the Job. The Document object is created by the
    [RFC2911] Send-Document and Send-URI operations and represents an Input
    Document to the Job. This specification also adds a Document Attributes
    group (and tag) to these Send-Document and Send-URI requests. The Document
    Attributes group contains any Document Template attributes to be applied to
    this Document object being created, overriding any corresponding Job
    Template attribute supplied at the job level (including the
    "document-overrides" operation attributes at the Job or Document level). A
    new Create-Document operation allows a client to supply the Document
    Attributes without the data (like Create-Job does for a Job object). Then
    the client sends the data content to that Document object using the new
    Send-Data operation. The client can also supply Document Attributes with
    the existing Send-Document and Send-URI operations to create Document
    objects with content data or a document reference, respectively.
    This specification also defines seven new operations for Document objects
    once they have been created: Cancel-Current-Document, Cancel-Document,
    Get-Document-Attributes, Get-Documents, Delete-Document,
    Set-Document-Attributes, and Validate-Document.
    This specification also lists all of the attributes defined in other IPP
    specifications to show their relationship to corresponding attributes
    defined in this IPP specification for use with the Document object. The
    full semantics of the "document-state", "document-state-reasons", and
    "document-state-message" Document Description attributes are given along
    side of the corresponding [RFC2911] "job-state", "job-state-reasons", and
    "job-state-message" Job Description attributes.
    The purpose for specifying the Document object is so that the print industry
    can have a common semantic specification for use in IPP, the PWG Semantic
    Model, the PWG Print Service Interface (PSI) project, and the Free Standards
    Group Job Ticket API which all have a Document object.

    Here is the Change Log:
    Version 0.4, 14 September 2002:
            1. Added the operation specifications.
            2. Added the Create-Document and Send-Data to be more parallel
    with Jobs and support PWG PSI.
            3. Resolved the 15 issues in version 0.3 as discussed on the
    mailing list.
            4. Added the Attribute Precedence section 5.
            5. Added [prod-print2] attributes.
            6. Added job-mandatory-attributes, job-cover-back,
    job-cover-front, job-copies, job-finishings, job-finishings-col.
    document-id-uri, and redirect-uri.

    Here are the 18 issues (which are also highlighted in the spec):
    ISSUE 01: Need to add all new attributes to CIP4/PODi/FSG IPP mapping
    document. When?

    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

    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

    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.

    ISSUE 05: OK, that Cancel-Document operation is OPTIONAL, while the
    Cancel-Job operation is REQUIRED by [RFC2911]?

     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?

    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?

    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.

    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?

    ISSUE 10: MUST Printer return document-id-uri? See Table 5

    ISSUE 11: MUST Printer support document-id-uri? See Table 5
    Table entry:
    document-id-uri uri MUST? ISSUE 10 MUST? ISSUE 11

    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

    ISSUE 13: MUST Printer support document-id-uri as a Document Description

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

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

    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?

    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.

    ISSUE 18: Or should the client be REQUIRED to support some of the Document

    This archive was generated by hypermail 2b29 : Wed Oct 23 2002 - 09:09:48 EDT