Nancy,
You are right, I would need a parallel structure by introducing a
<service>ServiceDefaults that would contain the existing
Default<service>JobTicket and a new element for
Default<service>DocumentTicket. I am a little confused by your second
paragraph since capabilities should provide all the allowed values and
default provide the single value used when not overridden in the user
request. As for DocumentForma read on.
I have been doing some comparisons between the PWG SM v1 and the current
schema. There are some defaults/supported values that are an issue.
This is because these values are associated with Document Description
values or properties of the submitted Digital Document. The elements in
question from the PWG Semantic Model v1 (and IPP) are the
PrinterDescription elements:
[CompressionDefault] (Missing in SM v1)
CompressionSupported
DocumentFormatDefault
DocumentFormatSupported
DocumetFormatDetailsDefault
DocumentFormatDetailsSupported
DocumentFormatVersionDefault
DocumentFormatVersioSupported
The <service>Document Description contains elements for
Compression
DocumentFormat
DocumentFormatDetails
DocumentFormatVersion
So by implementing default and capabilities for <service>DocumentTicket,
the defaults/supported above would be covered there.
Right now the Capabilities and Default for PrintJobDescription are
missing the elements associated with:
CompressionSupplied
DocumentCharsetSupplied
DocumentDigitalSignatureSupplied
DocumentFormatDetailsSupplied
DocumentFormatSupplied
DocumentFormatVersionSupplied
DocumentMessageSupplied
DocumentNameSupplied
Impressions
MediaSheets
They will be added. I got to thinking that FaxOut should have
compression and document format, and the others above, as well. When
FaxOut is submitting a document (push or pull) these elements are
applicable. (At least that will be my working group last call comment)
I think we should do #1 below and include a similar change to
<service>ServiceDefaults. In IPP the support and default values of
compression and the document format elements are properties of the
service description. Should the elements be replicated there as well?
Comments?
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
From: Nancy.Chen at okidata.com [mailto:Nancy.Chen at okidata.com]
Sent: Friday, September 17, 2010 12:34 PM
To: Zehler, Peter
Cc: mfd at pwg.org; mfd-bounces at pwg.org
Subject: Re: [MFD] Issue to resolve before publishing v1.111 <Response
Requested>
Hi Pete,
Depending on what we want tp provide for the
<service>ServiceCapabilities for Job and Document, I would say YES to
1), if users only want to know all the "features" available in a Job and
Document Ticket at Service level. Once we have all the features
supported, we also need a corresponding "default" for each supported
feature. I don't think we have a DedaultDocumentTicket at Service level
yet currently.
Would users not only want to know all those ticket "features" supported,
but also those supported "values" for each supported feature, such as
all supported Document Formats ?
DocumentFormat in a Job or Document Ticket only specifies the Document
Format value for a particular Job or Document. However, at a simple
request to a service, I would think users want to know all
DocumentFormat for all jobs and documents that are supported/configured
by a specific service instance before they submit a job to that service.
All,
What do you all think?
-Nancy
------------------------------------------------------------------------
--------------------------
Nancy Chen, PWG Vice-Chair
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: Nancy.Chen at okidata.com
"Zehler, Peter" <Peter.Zehler at xerox.com>
Sent by: mfd-bounces at pwg.org
09/17/2010 06:25 AM
To
<mfd at pwg.org>
cc
Subject
[MFD] Issue to resolve before publishing v1.111 <Response Requested>
All,
The issue I found is that <service>DocumentDescriptionCapabilities is
not represented in the model. The <service>ServiceCapabilities element
contains, in effect, the capabilities of a <service>JobTicket. That
does not seem to me to be the right place to "stuff" the
<service>DocumentDescriptionCapabilities. I was thinking that if we add
<service>JobTicketCapabilities and <service>DocumentTicketCapabilities
directly under service>ServiceCapabilities we would then have a place
for <service>DocumentDescriptionCapabilities. This has some advantages
such as a clearer mapping to the job or document ticket. The downside
is that <service>DocumentProcessingCapabilities would be in both
capabilities. I never thought of document processing as potentially
being different at the Job and Document level but I suppose that is
possible.
What is your opinion?
1) Add <service>JobTicketCapabilities and
<service>DocumentTicketCapabilities directly under
<service>ServiceCapabilities. The former contents of
<service>ServiceCapabilities will move to
<service>JobTicketCapabilities. <service>DocumentTicketCapabilities
will contain <service>DocumentDescriptionCapabilities,
<service>DocumentProcessingCapabilities and an extension point.
2) Add <service>DocumentDescriptionCapabilities to
<service>ServiceCapabilities.
3) Omit <service>DocumentDescriptionCapabilities
4) Other (please specify)
Pete
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
mfd mailing list
mfd at pwg.orghttps://www.pwg.org/mailman/listinfo/mfd
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100917/02133863/attachment-0001.html>