attachment-0001
<br><font size=2 face="sans-serif">Hi Ira,</font>
<br>
<br><font size=2 face="sans-serif">You brought up an important "ease-of-use"
issue. </font>
<br>
<br><font size=2 face="sans-serif">For duplicated attributes of "Supported"
and "Default" attributes in "Description" group of
a service, I don't think it's good to require administrator to replicate
everything after changes in one group. Hence I recommend the semantics
should mandate that if administrator set a Supported or Default attribute
in the Description group, the service MUST not only check the set of values
or the value set is in range and also ensure the same is set in the
corresponding attribute in the Supported or Default group for consistency.
And Vice Sersa if the adminstrator changed a default value in the Default
group or a set of allowed values in a Supported attribute, and the same
attribute existed in the Description group.</font>
<br>
<br><font size=2 face="sans-serif">All,</font>
<br>
<br><font size=2 face="sans-serif">Further issues? comments?</font>
<br>
<br><font size=2 face="sans-serif">Thanks,</font>
<br><font size=2 face="sans-serif">-Nancy</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Ira McDonald <blueroofmusic@gmail.com></b>
</font>
<p><font size=1 face="sans-serif">09/20/2010 11:01 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">Nancy.Chen@okidata.com, Ira McDonald
<blueroofmusic@gmail.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">"Zehler, Peter" <Peter.Zehler@xerox.com>,
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>Hi Pete and Nancy,<br>
</font></tt>
<br><tt><font size=2>I generally agree with your conclusions, but...one
question.<br>
</font></tt>
<br><tt><font size=2>What are the required semantics of, e.g., the duplicated<br>
DocumentFormatSupported and DocumentFormatDefault<br>
(in JobTicket capabilites and Service description elements)?<br>
</font></tt>
<br><tt><font size=2>Does changing one change the other?<br>
</font></tt>
<br><tt><font size=2>The IPP intent of XxxSupported and XxxDefault in the<br>
PrinterDescription were to allow Administrator control.<br>
</font></tt>
<br><tt><font size=2>Does the Administrator have to set them both places?<br>
(This reminds me of IPP parallel attributes yuckiness.)<br>
</font></tt>
<br><tt><font size=2>Cheers,<br>
- Ira<br>
</font></tt>
<br><tt><font size=2>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>
http://sites.google.com/site/blueroofmusic<br>
http://sites.google.com/site/highnorthinc<br>
mailto:blueroofmusic@gmail.com<br>
Christmas through April:</font></tt>
<br><tt><font size=2>579 Park Place Saline, MI 48176<br>
734-944-0094</font></tt>
<br><tt><font size=2>May to Christmas:<br>
PO Box 221 Grand Marais, MI 49839<br>
906-494-2434</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>On Mon, Sep 20, 2010 at 10:38 AM, <Nancy.Chen@okidata.com>
wrote:<br>
</font></tt>
<br><tt><font size=2>><br>
> Hi Pete.<br>
><br>
> >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.<br>
><br>
> I thought that you were simply going to put <service>JobTicket
and<br>
> <service>DocumentTicket(without change)into service capabilities.
I took a<br>
> look at the current MFD XML Schema, the JobTicket elements in service<br>
> capabilties already changed to contain "allowed values"
instead. Sorry for<br>
> the confusion.<br>
><br>
> >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>
><br>
> I incline to say "YES" for consistency with IPP. Also they
are REQUIRED<br>
> attributes for Printer-Description.<br>
><br>
> ALL: Anybody thinks it's too much redundancy? Please let us know.<br>
><br>
> -Nancy<br>
><br>
><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>
><br>
><br>
><br>
><br>
> *"Zehler, Peter" <Peter.Zehler@xerox.com>*<br>
><br>
> 09/17/2010 03:50 PM<br>
> To<br>
> <Nancy.Chen@okidata.com><br>
> cc<br>
> <mfd@pwg.org><br>
> Subject<br>
> RE: [MFD] Issue to resolve before publishing v1.111 <Response Requested><br>
><br>
><br>
><br>
> Nancy,<br>
><br>
><br>
><br>
> 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>
><br>
><br>
><br>
> 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>
><br>
><br>
><br>
> [CompressionDefault] (Missing in SM v1)<br>
><br>
> CompressionSupported<br>
><br>
> DocumentFormatDefault<br>
><br>
> DocumentFormatSupported<br>
><br>
> DocumetFormatDetailsDefault<br>
><br>
> DocumentFormatDetailsSupported<br>
><br>
> DocumentFormatVersionDefault<br>
><br>
> DocumentFormatVersioSupported<br>
><br>
><br>
><br>
> The <service>Document Description contains elements for<br>
><br>
> Compression<br>
><br>
> DocumentFormat<br>
><br>
> DocumentFormatDetails<br>
><br>
> DocumentFormatVersion<br>
><br>
><br>
><br>
> So by implementing default and capabilities for <service>DocumentTicket,<br>
> the defaults/supported above would be covered there.<br>
><br>
><br>
><br>
> Right now the Capabilities and Default for PrintJobDescription are<br>
> missing the elements associated with:<br>
><br>
> CompressionSupplied<br>
><br>
> DocumentCharsetSupplied<br>
><br>
> DocumentDigitalSignatureSupplied<br>
><br>
> DocumentFormatDetailsSupplied<br>
><br>
> DocumentFormatSupplied<br>
><br>
> DocumentFormatVersionSupplied<br>
><br>
> DocumentMessageSupplied<br>
><br>
> DocumentNameSupplied<br>
><br>
> Impressions<br>
><br>
> MediaSheets<br>
><br>
><br>
><br>
> 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>
><br>
><br>
><br>
> 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>
><br>
><br>
><br>
> Comments?<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Peter Zehler<br>
><br>
> Xerox Research Center Webster<br>
><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>
><br>
><br>
><br>
> 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>
><br>
><br>
><br>
><br>
> Hi Pete,<br>
><br>
> 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>
><br>
> 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>
><br>
> 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>
><br>
><br>
> All,<br>
> What do you all think?<br>
><br>
> -Nancy<br>
><br>
> ------------------------------------------------------------------------<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>
><br>
><br>
><br>
><br>
><br>
> "Zehler, Peter" <Peter.Zehler@xerox.com><br>
> Sent by: mfd-bounces@pwg.org<br>
><br>
> 09/17/2010 06:25 AM<br>
><br>
> To<br>
><br>
> <mfd@pwg.org><br>
><br>
> cc<br>
><br>
><br>
> Subject<br>
><br>
> [MFD] Issue to resolve before publishing v1.111 <Response Requested><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> All,<br>
><br>
><br>
><br>
> 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>
><br>
><br>
><br>
> What is your opinion?<br>
><br>
> 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>
><br>
> 2) Add <service>DocumentDescriptionCapabilities
to<br>
> <service>ServiceCapabilities.<br>
><br>
> 3) Omit <service>DocumentDescriptionCapabilities<br>
><br>
> 4) Other (please specify)<br>
><br>
><br>
><br>
><br>
><br>
> Pete<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> Peter Zehler<br>
><br>
> 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>
><br>
><br>
><br>
><br>
> --<br>
> This message has been scanned for viruses and<br>
> dangerous content by MailScanner, and is<br>
> believed to be clean.<br>
><br>
><br>
> _______________________________________________<br>
> mfd mailing list<br>
> mfd@pwg.org<br>
> https://www.pwg.org/mailman/listinfo/mfd<br>
><br>
><br>
><br>
> --<br>
> This message has been scanned for viruses and<br>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>,
and is<br>
> believed to be clean.<br>
><br>
> _______________________________________________<br>
> mfd mailing list<br>
> mfd@pwg.org<br>
> https://www.pwg.org/mailman/listinfo/mfd<br>
><br>
></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.