attachment-0001
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 & 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"><<a href="mailto:Nancy.Chen@okidata.com">Nancy.Chen@okidata.com</a>></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">>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. </font></tt>
<br>
<br></div><tt><font size="2">I thought that you were simply going to put <service>JobTicket
and <service>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 "allowed values"
instead. Sorry for the confusion.</font></tt>
<br><div class="im">
<br><tt><font size="2">>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?</font></tt>
<br>
<br></div><tt><font size="2">I incline to say "YES" for consistency with
IPP. Also they are REQUIRED attributes for Printer-Description. </font></tt>
<br>
<br><tt><font size="2">ALL: Anybody thinks it'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>"Zehler, Peter"
<<a href="mailto:Peter.Zehler@xerox.com" target="_blank">Peter.Zehler@xerox.com</a>></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"><<a href="mailto:Nancy.Chen@okidata.com" target="_blank">Nancy.Chen@okidata.com</a>></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"><<a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>></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 <Response Requested></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>
<service>ServiceDefaults that would contain the existing<br>
Default<service>JobTicket and a new element for<br>
Default<service>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 <service>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 <service>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>
<service>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 <mailto:<a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a>><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 <Response<br>
Requested><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>
<service>ServiceCapabilities for Job and Document, I would say YES
to<br>
1), if users only want to know all the "features" available in
a Job and<br>
Document Ticket at Service level. Once we have all the features<br>
supported, we also need a corresponding "default" for each supported<br>
feature. I don'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
"features" supported,<br>
but also those supported "values" 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">"Zehler, Peter" <<a href="mailto:Peter.Zehler@xerox.com" target="_blank">Peter.Zehler@xerox.com</a>><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"><<a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>><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 <Response
Requested><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 <service>DocumentDescriptionCapabilities
is<br>
not represented in the model. The <service>ServiceCapabilities
element<br>
contains, in effect, the capabilities of a <service>JobTicket. That<br>
does not seem to me to be the right place to "stuff" the<br>
<service>DocumentDescriptionCapabilities. I was thinking that
if we add<br>
<service>JobTicketCapabilities and <service>DocumentTicketCapabilities<br>
directly under service>ServiceCapabilities we would then have a place<br>
for <service>DocumentDescriptionCapabilities. This has some
advantages<br>
such as a clearer mapping to the job or document ticket. The downside<br>
is that <service>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 <service>JobTicketCapabilities
and<br>
<service>DocumentTicketCapabilities directly under<br>
<service>ServiceCapabilities. The former contents of<br>
<service>ServiceCapabilities will move to<br>
<service>JobTicketCapabilities. <service>DocumentTicketCapabilities<br>
will contain <service>DocumentDescriptionCapabilities,<br>
<service>DocumentProcessingCapabilities and an extension point.<br>
</font></tt>
<br><tt><font size="2">2) Add <service>DocumentDescriptionCapabilities
to<br>
<service>ServiceCapabilities.<br>
</font></tt>
<br><tt><font size="2">3) Omit <service>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 <mailto:<a href="mailto:Peter.Zehler@Xerox.com" target="_blank">Peter.Zehler@Xerox.com</a>><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>
<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.