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/b9b86ed5/attachment-0001.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/mfd/attachments/20100917/b9b86ed5/attachment.htm>