attachment.htm

Hi Pete and Nancy,<br><br>I generally agree with your conclusions, but...one question.<br><br>What are the required semantics of, e.g., the duplicated <br>DocumentFormatSupported and DocumentFormatDefault<br>(in JobTicket capabilites and Service description elements)?<br>
<br>Does changing one change the other?<br><br>The IPP intent of XxxSupported and XxxDefault in the<br>PrinterDescription were to allow Administrator control.<br><br>Does the Administrator have to set them both places?<br>
(This reminds me of IPP parallel attributes yuckiness.)<br><br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Co-Chair - TCG Hardcopy WG<br>
IETF Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music/High North Inc<br><a href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color: rgb(102, 0, 204);" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Christmas through April:<br>  579 Park Place  Saline, MI  48176<br>  734-944-0094<br>May to Christmas:<br>  PO Box 221  Grand Marais, MI 49839<br>
  906-494-2434<div style="display: inline;"></div><div style="display: inline;"></div><div style="display: inline;"></div><br>
<br><br><div class="gmail_quote">On Mon, Sep 20, 2010 at 10:38 AM,  <span dir="ltr">&lt;<a href="mailto:Nancy.Chen@okidata.com">Nancy.Chen@okidata.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br><font face="sans-serif" size="2">Hi Pete.</font>
<br><div class="im">
<br><tt><font size="2">&gt;I am a little confused by your second<br>
&gt;paragraph since capabilities should provide all the allowed values
and<br>
&gt;default provide the single value used when not overridden in the user<br>
&gt;request. </font></tt>
<br>
<br></div><tt><font size="2">I thought that you were simply going to put &lt;service&gt;JobTicket
and &lt;service&gt;DocumentTicket(without change)into service capabilities.
I took a look at the current MFD XML Schema, the JobTicket elements in
service capabilties already changed to contain &quot;allowed values&quot;
instead. Sorry for the confusion.</font></tt>
<br><div class="im">
<br><tt><font size="2">&gt;In IPP the support and default values of<br>
&gt;compression and the document format elements are properties of the<br>
&gt;service description.  Should the elements be replicated there
as well?</font></tt>
<br>
<br></div><tt><font size="2">I incline to say &quot;YES&quot; for consistency with
IPP. Also they are REQUIRED attributes for Printer-Description. </font></tt>
<br>
<br><tt><font size="2">ALL: Anybody thinks it&#39;s too much redundancy? Please
let us know.</font></tt>
<br><div class="im">
<br><tt><font size="2">-Nancy</font></tt>
<br><tt><font size="2"><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: <a href="mailto:Nancy.Chen@okidata.com" target="_blank">Nancy.Chen@okidata.com</a></font></tt>
<br>
<br>
<br>
<br>
<br>
</div><table width="100%">
<tbody><tr valign="top">
<td width="40%"><div class="im"><font face="sans-serif" size="1"><b>&quot;Zehler, Peter&quot;
&lt;<a href="mailto:Peter.Zehler@xerox.com" target="_blank">Peter.Zehler@xerox.com</a>&gt;</b> </font>
</div><p><font face="sans-serif" size="1">09/17/2010 03:50 PM</font>
</p></td><td width="59%">
<table width="100%">
<tbody><tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">To</font></div>
</td><td><font face="sans-serif" size="1">&lt;<a href="mailto:Nancy.Chen@okidata.com" target="_blank">Nancy.Chen@okidata.com</a>&gt;</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">cc</font></div>
</td><td><font face="sans-serif" size="1">&lt;<a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>&gt;</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font face="sans-serif" size="1">Subject</font></div>
</td><td><font face="sans-serif" size="1">RE: [MFD] Issue to resolve before publishing
v1.111 &lt;Response Requested&gt;</font></td></tr></tbody></table>
<br>
<table>
<tbody><tr valign="top">
<td>
</td><td></td></tr></tbody></table>
<br></td></tr></tbody></table><div><div></div><div class="h5">
<br>
<br><tt><font size="2">Nancy,<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">You are right, I would need a parallel structure by
introducing a<br>
&lt;service&gt;ServiceDefaults that would contain the existing<br>
Default&lt;service&gt;JobTicket and a new element for<br>
Default&lt;service&gt;DocumentTicket.  I am a little confused by your
second<br>
paragraph since capabilities should provide all the allowed values and<br>
default provide the single value used when not overridden in the user<br>
request.  As for DocumentForma read on.<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">I have been doing some comparisons between the PWG
SM v1 and the current<br>
schema.  There are some defaults/supported values that are an issue.<br>
This is because these values are associated with  Document Description<br>
values or properties of the submitted Digital Document.  The elements
in<br>
question from the PWG Semantic Model v1 (and IPP) are the<br>
PrinterDescription elements:<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">[CompressionDefault]  (Missing in SM v1)<br>
</font></tt>
<br><tt><font size="2">CompressionSupported<br>
</font></tt>
<br><tt><font size="2">DocumentFormatDefault<br>
</font></tt>
<br><tt><font size="2">DocumentFormatSupported<br>
</font></tt>
<br><tt><font size="2">DocumetFormatDetailsDefault<br>
</font></tt>
<br><tt><font size="2">DocumentFormatDetailsSupported<br>
</font></tt>
<br><tt><font size="2">DocumentFormatVersionDefault<br>
</font></tt>
<br><tt><font size="2">DocumentFormatVersioSupported<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">The &lt;service&gt;Document Description contains elements
for<br>
</font></tt>
<br><tt><font size="2">Compression<br>
</font></tt>
<br><tt><font size="2">DocumentFormat<br>
</font></tt>
<br><tt><font size="2">DocumentFormatDetails<br>
</font></tt>
<br><tt><font size="2">DocumentFormatVersion<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">So by implementing default and capabilities for &lt;service&gt;DocumentTicket,<br>
the defaults/supported above would be covered there.<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">Right now the Capabilities and Default for PrintJobDescription
are<br>
missing the elements associated with:<br>
</font></tt>
<br><tt><font size="2">CompressionSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentCharsetSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentDigitalSignatureSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentFormatDetailsSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentFormatSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentFormatVersionSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentMessageSupplied<br>
</font></tt>
<br><tt><font size="2">DocumentNameSupplied<br>
</font></tt>
<br><tt><font size="2">Impressions<br>
</font></tt>
<br><tt><font size="2">MediaSheets<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">They will be added.   I got to thinking that
FaxOut should have<br>
compression and document format, and the others above, as well.  When<br>
FaxOut is submitting a document (push or pull) these elements are<br>
applicable.  (At least that will be my working group last call comment)<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">I think we should do #1 below and include a similar
change to<br>
&lt;service&gt;ServiceDefaults.    In IPP the support and default
values of<br>
compression and the document format elements are properties of the<br>
service description.  Should the elements be replicated there as well?<br>
</font></tt>
<br>
<br>
<br><tt><font size="2">Comments?<br>
</font></tt>
<br>
<br>
<br>
<br>
<br>
<br>
<br><tt><font size="2">Peter Zehler<br>
</font></tt>
<br></div></div><tt><font size="2">Xerox Research Center Webster<div><div></div><div class="h5"><br>
Email: Peter.Zehler@Xerox.com &lt;mailto:<a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a>&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>
</div></div></font></tt><div><div></div><div class="h5">
<br>
<br>
<br><tt><font size="2">From: <a href="mailto:Nancy.Chen@okidata.com" target="_blank">Nancy.Chen@okidata.com</a> [mailto:<a href="mailto:Nancy.Chen@okidata.com" target="_blank">Nancy.Chen@okidata.com</a>]<br>
Sent: Friday, September 17, 2010 12:34 PM<br>
To: Zehler, Peter<br>
Cc: <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>; <a href="mailto:mfd-bounces@pwg.org" target="_blank">mfd-bounces@pwg.org</a><br>
Subject: Re: [MFD] Issue to resolve before publishing v1.111 &lt;Response<br>
Requested&gt;<br>
</font></tt>
<br>
<br>
<br>
<br><tt><font size="2">Hi Pete,<br>
</font></tt>
<br><tt><font size="2">Depending on what we want tp provide for the<br>
&lt;service&gt;ServiceCapabilities for Job and Document, I would say YES
to<br>
1), if users only want to know all the &quot;features&quot; available in
a Job and<br>
Document Ticket at Service level. Once we have all the features<br>
supported, we also need a corresponding &quot;default&quot; for each supported<br>
feature. I don&#39;t think we have a DedaultDocumentTicket at Service level<br>
yet currently.<br>
</font></tt>
<br><tt><font size="2">Would users not only want to know all those ticket
&quot;features&quot; supported,<br>
but also those supported &quot;values&quot; for each supported feature,
such as<br>
all supported Document Formats ?<br>
</font></tt>
<br><tt><font size="2">DocumentFormat in a Job or Document Ticket only specifies
the Document<br>
Format value for a particular Job or Document. However, at a simple<br>
request to a service, I would think users want to know all<br>
DocumentFormat for all jobs and documents that are supported/configured<br>
by a specific service instance before they submit a job to that service.<br>
</font></tt>
<br>
<br><tt><font size="2">All,<br>
What do you all think?<br>
</font></tt>
<br><tt><font size="2">-Nancy<br>
</font></tt>
<br><tt><font size="2">------------------------------------------------------------------------<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: <a href="mailto:Nancy.Chen@okidata.com" target="_blank">Nancy.Chen@okidata.com</a><br>
</font></tt>
<br>
<br>
<br>
<br>
<br><tt><font size="2">&quot;Zehler, Peter&quot; &lt;<a href="mailto:Peter.Zehler@xerox.com" target="_blank">Peter.Zehler@xerox.com</a>&gt;<br>
Sent by: <a href="mailto:mfd-bounces@pwg.org" target="_blank">mfd-bounces@pwg.org</a><br>
</font></tt>
<br><tt><font size="2">09/17/2010 06:25 AM<br>
</font></tt>
<br><tt><font size="2">To<br>
</font></tt>
<br><tt><font size="2">&lt;<a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>&gt;<br>
</font></tt>
<br><tt><font size="2">cc<br>
</font></tt>
<br>
<br><tt><font size="2">Subject<br>
</font></tt>
<br><tt><font size="2">[MFD] Issue to resolve before publishing v1.111 &lt;Response
Requested&gt;<br>
</font></tt>
<br>
<br>
<br>
<br>
<br>
<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.  The &lt;service&gt;ServiceCapabilities
element<br>
contains, in effect, the capabilities of a &lt;service&gt;JobTicket.  That<br>
does not seem to me to be the right place to &quot;stuff&quot; the<br>
&lt;service&gt;DocumentDescriptionCapabilities.  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.  This has some
advantages<br>
such as a clearer mapping to the job or document ticket.  The downside<br>
is that &lt;service&gt;DocumentProcessingCapabilities would be in both<br>
capabilities.  I never thought of document processing  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)      Add &lt;service&gt;JobTicketCapabilities
and<br>
&lt;service&gt;DocumentTicketCapabilities directly under<br>
&lt;service&gt;ServiceCapabilities.  The former contents of<br>
&lt;service&gt;ServiceCapabilities will move to<br>
&lt;service&gt;JobTicketCapabilities.  &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)      Add &lt;service&gt;DocumentDescriptionCapabilities
to<br>
&lt;service&gt;ServiceCapabilities.<br>
</font></tt>
<br><tt><font size="2">3)      Omit &lt;service&gt;DocumentDescriptionCapabilities<br>
</font></tt>
<br><tt><font size="2">4)      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:<a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a>&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.<br>
</font></tt>
<br>
<br><tt><font size="2">_______________________________________________<br>
mfd mailing list<br>
<a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/mfd" target="_blank">https://www.pwg.org/mailman/listinfo/mfd</a></font></tt>
<br>
<br>
<br><br>-- 
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.


</div></div><br>_______________________________________________<br>
mfd mailing list<br>
<a href="mailto:mfd@pwg.org">mfd@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/mfd" target="_blank">https://www.pwg.org/mailman/listinfo/mfd</a><br>
<br></blockquote></div><br>