All,
The PWG Semantic Model Work Group will host the review of the Document
Object Specification in their October 24th telecon. This review is in
preparation for the face to face review in New Orleans during the afternoon
of the Semantic Model day. I'm sending this note out to allow for adequate
time for people to review the document. Attached below is Tom Hasting's
information on the document and the teleconference information for the 24th.
A detailed agenda will be sent out early next week. I expect to discuss the
18 issues Tom has called out. Please send any comments you may have on the
document to the Semantic Model mail list (sm@pwg.org)
To Subscribe to the Semantic Model Mail List: Send e-mail to
majordomo@pwg.org, put SUBSCRIBE or SUBSCRIBE SM in the body (not subject).
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
____________________________________________________________________________
__________________
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)
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-021014.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-021014.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-021014-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_DOC/IPP-Document-Object-021014-rev.doc
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
'separate-documents-collated-copies'.
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
well?
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
operation?
ISSUE 13: MUST Printer support document-id-uri as a Document Description
attribute?
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
operations?
Please send comments.
Tom
____________________________________________________________________________
__________________
Teleconference Information:
________________________________________________________
Dial in Info:
Phone Number: (877) 776-6306
(Phone Number for Xerox Employees: 8*594-0576)
PARTICIPANT PASSCODE: 437874#
________________________________________________
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.
-------------------------
FIRST TIME USERS
-------------------------
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:
https://hp.webex.com/join/
Then click join unlisted meeting.
Use the info below:
-------------------------
Webex MEETING SUMMARY
-------------------------
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
Host:
Bob Taylor (HP)
___________________________________________________
____________________________________________________________________________
__________________
This archive was generated by hypermail 2b29 : Thu Oct 17 2002 - 09:02:47 EDT