attachment-0001


<br><font size=2 face="sans-serif">Hi Pete,</font>
<br>
<br><font size=2 face="sans-serif">Depending on what we want tp provide
for the &lt;service&gt;ServiceCapabilities for Job and Document, I would
say YES to 1), if users only want to know all the &quot;features&quot;
available in a Job and Document Ticket at Service level. Once we have all
the features supported, we also need a corresponding &quot;default&quot;
for each supported feature. I don't think we have a DedaultDocumentTicket
at Service level yet currently.</font>
<br>
<br><font size=2 face="sans-serif">Would users not only want to know all
those ticket &quot;features&quot; supported, but also those supported &quot;values&quot;
for each supported feature, such as all supported Document Formats ?</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">All,</font>
<br><font size=2 face="sans-serif">What do you all think?</font>
<br>
<br><font size=2 face="sans-serif">-Nancy</font>
<br><font size=2 face="sans-serif"><br>
--------------------------------------------------------------------------------------------------<br>
Nancy Chen, PWG Vice-Chair<br>
Principal Engineer<br>
Solutions and Technology<br>
Oki Data<br>
2000 Bishops Gate Blvd.<br>
Mt. Laurel, NJ 08054<br>
Phone: (856)222-7006<br>
Email: Nancy.Chen@okidata.com</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Zehler, Peter&quot;
&lt;Peter.Zehler@xerox.com&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: mfd-bounces@pwg.org</font>
<p><font size=1 face="sans-serif">09/17/2010 06:25 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">&lt;mfd@pwg.org&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[MFD] Issue to resolve before publishing
v1.111 &lt;Response Requested&gt;</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><tt><font size=2>All,<br>
</font></tt>
<br>
<br>
<br><tt><font size=2>The issue I found is that &lt;service&gt;DocumentDescriptionCapabilities
is<br>
not represented in the model. &nbsp;The &lt;service&gt;ServiceCapabilities
element<br>
contains, in effect, the capabilities of a &lt;service&gt;JobTicket. &nbsp;That<br>
does not seem to me to be the right place to &quot;stuff&quot; the<br>
&lt;service&gt;DocumentDescriptionCapabilities. &nbsp;I was thinking that
if we add<br>
&lt;service&gt;JobTicketCapabilities and &lt;service&gt;DocumentTicketCapabilities<br>
directly under service&gt;ServiceCapabilities we would then have a place<br>
for &lt;service&gt;DocumentDescriptionCapabilities. &nbsp;This has some
advantages<br>
such as a clearer mapping to the job or document ticket. &nbsp;The downside<br>
is that &lt;service&gt;DocumentProcessingCapabilities would be in both<br>
capabilities. &nbsp;I never thought of document processing &nbsp;as potentially<br>
being different at the Job and Document level but I suppose that is<br>
possible.<br>
</font></tt>
<br>
<br>
<br><tt><font size=2>What is your opinion?<br>
</font></tt>
<br><tt><font size=2>1) &nbsp; &nbsp; &nbsp;Add &lt;service&gt;JobTicketCapabilities
and<br>
&lt;service&gt;DocumentTicketCapabilities directly under<br>
&lt;service&gt;ServiceCapabilities. &nbsp;The former contents of<br>
&lt;service&gt;ServiceCapabilities will move to<br>
&lt;service&gt;JobTicketCapabilities. &nbsp;&lt;service&gt;DocumentTicketCapabilities<br>
will contain &lt;service&gt;DocumentDescriptionCapabilities,<br>
&lt;service&gt;DocumentProcessingCapabilities and an extension point.<br>
</font></tt>
<br><tt><font size=2>2) &nbsp; &nbsp; &nbsp;Add &lt;service&gt;DocumentDescriptionCapabilities
to<br>
&lt;service&gt;ServiceCapabilities.<br>
</font></tt>
<br><tt><font size=2>3) &nbsp; &nbsp; &nbsp;Omit &lt;service&gt;DocumentDescriptionCapabilities<br>
</font></tt>
<br><tt><font size=2>4) &nbsp; &nbsp; &nbsp;Other (please specify)<br>
</font></tt>
<br>
<br>
<br>
<br>
<br><tt><font size=2>Pete<br>
</font></tt>
<br>
<br>
<br>
<br>
<br>
<br>
<br><tt><font size=2>Peter Zehler<br>
</font></tt>
<br><tt><font size=2>Xerox Research Center Webster<br>
Email: Peter.Zehler@Xerox.com &lt;mailto:Peter.Zehler@Xerox.com&gt;<br>
Voice: (585) 265-8755<br>
FAX: (585) 265-7441<br>
US Mail: Peter Zehler<br>
Xerox Corp.<br>
800 Phillips Rd.<br>
M/S 128-25E<br>
Webster NY, 14580-9701<br>
</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>--<br>
This message has been scanned for viruses and<br>
dangerous content by MailScanner, and is<br>
believed to be clean.</font></tt>
<br>
<br>
<br><tt><font size=2>_______________________________________________<br>
mfd mailing list<br>
mfd@pwg.org<br>
https://www.pwg.org/mailman/listinfo/mfd</font></tt>
<br>
<br><br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.