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:54 EDT