Semantic Model Mail Archive: SM> First Draft IPP Document Ob

Semantic Model Mail Archive: SM> First Draft IPP Document Ob

SM> First Draft IPP Document Object spec down-loaded

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Aug 22 2002 - 16:52:17 EDT

  • Next message: Zehler, Peter: "SM> Semantic documernts"

    Peter Zehler posted the next draft (0.07) of the PWG Semantic Model on
    August 16 at:
    ftp://ftp.pwg.org/pub/pwg/Semantic_model/PWG-Semantic-Model-07-020816.pdf

    The PWG Semantic Model document is intended to be short and to refer to
    other documents for the details (mostly IPP documents). The PWG Semantic
    Model is also intended to be used by other groups that are developing print
    semantics in order to make any API, protocol, and job ticket semantics as
    similar as possible, such as those being developed by other PWG sub-groups
    and other groups, such as the sub-groups in the Free Standards Group
    OpenPrinting WG.

    The PWG Semantic Model adds a new Document object to the model. It re-uses
    most of the existing Job attributes for the Document object. However, the
    detailed specification for the Document object, operations, attributes, and
    values is needed for the Semantic Model to reference. This mail note
    announces a first draft of such a 36-page document. Its available at:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/document-object-v094.pdf 200Kb
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/document-object-v094.doc 1000Kb
    ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/document-object-v094.zip 140Kb -
    just the .doc

    The .doc file is 1Mbyte, probably because of the two Visio state diagrams,
    or maybe the tables.

    This IPP Document Object specification is intended to give a common semantic
    model for the Document object for use by IPP (ipp@pwg.org), the PWG Semantic
    Model (sm@pwg.org), the PWG Print Services Interface (PSI) (ps@pwg.org), and
    the Free Software Group (FSG) PAPI (printing-spool@freestandards.org) and
    Job Ticket APIs (printing-jobticket@freestandards.org).

    For more info on the 3 PWG sub-groups, visit http://www.pwg.org
    For more info on the 2 FSG sub-groups, visit
    http://www.freestandards.org/openprinting

    The PWG is meeting next week in Santa Fe:
    Monday Aug 26: Internet FAX
    Tuesday Aug 27: PWG Plenary/XHTML-print
    Wednesday, Aug 28: Print Services Interface (PSI)
    (Thursday UPnP).

    There are 9 issues (included below) in the document that would be good to
    handle at some point in the agenda. And any other issues raised by reading
    the spec would be good too. Since there are 5 groups working on this (see
    To list), I suggest that any comments be sent to all lists as a reply all.

    Here is the Abstract:

    This document is an IPP extension proposal to extend the IPP/PWG semantics
    to include a Document object. The Job object is said to contain one or more
    Document objects which are passive objects operated on by the Job. The
    Document object is created by the existing Send-Document and Send-URI
    operations. However, a client can supply additional Document Template
    attributes with each document and new Document Description attributes are
    defined. Also there are seven new operations defined for Documents once
    they have been created.

    The purpose for specifying the Document object, is so that we can have a
    common specification for use in IPP, the PWG Semantic Model, the PWG PSI
    project, and the Free Standards Group Job Ticket API which all have a
    Document object.

    Here are the 9 issues:

    ISSUE 01: Should we publish this document as an IETF standards track
    document or as an IEEE-ISTO standard? If the former, since the IETF IPP WG
    is in the process of being closed down when all the current specifications
    are published, Peter and Tom will propose the specification as individual
    authors standards track contribution (after PWG review). If the latter, it
    will be published as one more IEEE-ISTO standard in the 5100.n series.

    ---------------------------
    According to [coll], the "document-overrides" (collection) attribute MAY be
    supplied by the client in a Send-Document or Send-URI request as an
    Operation attribute to apply document overrides to this and/or subsequent
    documents in the job. See the "document-overrides" Job Template attribute
    in Table 3 for the listing of the member attributes. However, with the
    introduction of the Document object, the "document-overrides" (collection)
    attribute SHOULD NOT be used (either as a Job Template attribute or an
    Operation attribute). Instead, the client simply supplies the Document
    Template attributes (see Table 3) for each Document Creation request (in a
    new Document Template attribute group) without needing a collection.

    ISSUE 02: What do we want to do with the "document-overrides" collection
    attributes when supporting the Document object, which is no longer needed as
    either a Job Template, Document Template, or operation attribute in Job and
    Document Creation requests?

    ---------------------------
    Similarly, according to [coll], the "page-overrides" (collection) attribute
    MAY be supplied by the client in a Send-Document or Send-URI request as an
    Operation attribute to apply page overrides to this and/or subsequent
    documents in the job. See the "page-overrides" Job Template attribute in
    Table 3 for the listing of the member attributes. However, with the
    introduction of the Document object, the "page-overrides" (collection)
    attribute SHOULD be more simply supplied as one of the Document Template
    attributes for this document only.

    ISSUE 03: What do we want to do with the "page-overrides" collection
    attributes when supporting the Document object, which is still needed as a
    Job Template and Document Template attribute for overriding attributes in
    specified page ranges, but is not needed as an operation attribute on
    Document Creation requests?

    ---------------------------
    ISSUE 04: Is the following query behavior for Job and Document objects OK?
    Job Template and Document Template attributes are OPTIONAL for a Printer to
    support and for a client to supply in a Job Creation or Document Creation
    request or a Document Overrides or Page Overrides. If a Printer supports a
    Job Template or Document Template attribute, then it MUST copy the supplied
    attribute to the Job or Document object, respectively so that a client MAY
    query the attributes in subsequent Get-Job-Attributes/Get-Jobs and
    Get-Document-Attributes/Get-Documents operations, respectively. The effect
    of Job Template Attributes supplied in Job Creation requests are inherited
    by the Document objects, unless the Document Creation operation supplies the
    attribute with a different value. However, the Printer MUST NOT propagate
    Job Template attributes supplied in Job Creation operations to the Document
    object. Similarly, the Printer MUST NOT promote Document Template attributes
    up to the Job object when no corresponding Job Template attribute was
    supplied in the Job Creation operation. Thus the Printer returns in queries
    only Job Template and Document Template attributes that were actually
    supplied by a client.

    ---------------------------
    [job-] indicates an attribute that shouldn't have had a "job-" prefix in
    its name in [RFC2911], so that the same attribute could also apply to the
    Document object as a Document Description attribute. Note: For the PWG
    Semantic Model, the "job-" prefix is proposed to be dropped.

            ISSUE 05: Should we sort the attributes ignoring the [job-]?
    Current the "job-" is used in the sort for attributes.

            ISSUE 06: How will we register these attributes with IANA, since
    they will be registered for IPP use, with the "job-" prefix. Do we add the
    ones without "job-" as aliases to the IANA registry as is done for charset
    registrations?

    ---------------------------
    [job-] indicates a state reason keyword value that shouldn't have had a
    "job-" prefix in its name in [RFC2911], so that the same value could also
    apply at the Document level as a "document-state-reasons" attribute value.
    Note: For the PWG Semantic Model, the "job-" prefix will be dropped. For
    purposes of sorting in Table 6, the "[job-]" prefix is ignored, since the
    PWG Semantic Model name is proposed without the prefix.

            ISSUE 07: Should we sort the attributes values including the
    [job-]? Currently the "job-" is ignored in the sort for attribute values.

            ISSUE 08: How will we register these attribute values with IANA,
    since they will be registered for IPP use, with the "job-" prefix. Do we
    add the ones without "job-" as aliases to the IANA registry as is done for
    charset registrations?

    ---------------------------
    TBD - one to list the Document Template keyword attribute names supported.
    ISSUE 09: What other Printer Description attributes are needed, if any?

    Send comments to the mailing lists.

    Thanks,
    Tom



    This archive was generated by hypermail 2b29 : Thu Aug 22 2002 - 16:53:21 EDT