attachment-0001
<br><font size=2 face="sans-serif">Hi Pete.</font>
<br>
<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><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>
<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><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>
<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: Nancy.Chen@okidata.com</font></tt>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Zehler, Peter"
<Peter.Zehler@xerox.com></b> </font>
<p><font size=1 face="sans-serif">09/17/2010 03:50 PM</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"><Nancy.Chen@okidata.com></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif"><mfd@pwg.org></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">RE: [MFD] Issue to resolve before publishing
v1.111 <Response Requested></font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<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><tt><font size=2>Xerox Research Center Webster<br>
Email: Peter.Zehler@Xerox.com <mailto:Peter.Zehler@Xerox.com><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><tt><font size=2>From: Nancy.Chen@okidata.com [mailto:Nancy.Chen@okidata.com]<br>
Sent: Friday, September 17, 2010 12:34 PM<br>
To: Zehler, Peter<br>
Cc: mfd@pwg.org; mfd-bounces@pwg.org<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: Nancy.Chen@okidata.com<br>
</font></tt>
<br>
<br>
<br>
<br>
<br><tt><font size=2>"Zehler, Peter" <Peter.Zehler@xerox.com><br>
Sent by: mfd-bounces@pwg.org<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><mfd@pwg.org><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:Peter.Zehler@Xerox.com><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>
mfd@pwg.org<br>
https://www.pwg.org/mailman/listinfo/mfd</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/"><b>MailScanner</b></a>, and is
<br />believed to be clean.