attachment-0002

<div dir="ltr"><div><div><div><div><div><div>Hi Paul,<br><br></div>In many cases inter-attribute constraints are implementation-defined rather than being<br></div>statically spec-defined.<br><br></div>IPP Everywhere has a standard mechanism for discovering inter-attribute constraints<br>
</div><div>(supported in the PWG SM XML Schema).<br><br></div>This information does not belong in a PWG SM 2.0 architecture spec IMHO.<br><br></div>Cheers,<br></div>- Ira<br><br></div><div class="gmail_extra"><br clear="all">
<div>Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP &amp; Printer MIB<br>Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" 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>
Winter  579 Park Place  Saline, MI  48176  734-944-0094<br>Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div>
<div></div><div></div><div></div><div></div></div>
<br><br><div class="gmail_quote">On Sat, Jul 6, 2013 at 9:15 PM, Paul Tykodi <span dir="ltr">&lt;<a href="mailto:ptykodi@tykodi.com" target="_blank">ptykodi@tykodi.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hi,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I might not have expressed the concept that Pete described to me correctly. With PPD files, there is frequently a large section describing UI Constraints. These are lists of items that customers cannot use together. If they try to select a set of options not supported by the target device, some type of visual error icon is displayed to show them what options cannot be used together.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">The constraints that Pete mentioned, which could not be represented in the XML, were the PWG elements that couldn’t be used together. He was not referring to constraints regarding how information is formatted for a particular element.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">He told me that the constraints describing PWG elements that cannot be used together have previously been documented in the tables.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I was speaking about these particular constraints when I put forward the question as to whether we might want to consider listing them together in their own section.<u></u><u></u></span></p>
<div class="im"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Best Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">/Paul<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">--</span><span style="color:#1f497d"><u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Paul Tykodi<br>
Principal Consultant<br>TCS - Tykodi Consulting Services LLC<br><br>Tel/Fax: <a href="tel:603-343-1820" value="+16033431820" target="_blank">603-343-1820</a><br>Mobile:  <a href="tel:603-866-0712" value="+16038660712" target="_blank">603-866-0712</a><br>
E-mail:  <a href="mailto:ptykodi@tykodi.com" target="_blank">ptykodi@tykodi.com</a></span><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1f497d"><br></span><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">WWW:  </span><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1f497d"><a href="http://www.tykodi.com/" target="_blank"><span style="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">http://www.tykodi.com</span></a></span><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u><u></u></span></p>
</div><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Ira McDonald [mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>] <br>
<b>Sent:</b> Saturday, July 06, 2013 2:17 PM<br><b>To:</b> William A Wagner; Ira McDonald<br><b>Cc:</b> Paul Tykodi; Michael Sweet; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a></span></p><div><div class="h5">
<br><b>Subject:</b> Re: [MFD] Schema Element Table format for Imaging System Model Spec<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><div><div><div><div><div><p class="MsoNormal" style="margin-bottom:12.0pt">
Hi Bill,<u></u><u></u></p></div><p class="MsoNormal">I agree that listing constraints is busywork and error-prone - leave the constraints<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">for the underlying IPP or MIB objects - they&#39;re reflected in the SM XML schema.<u></u><u></u></p>
</div><p class="MsoNormal">Cheers,<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">- Ira<u></u><u></u></p></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><p class="MsoNormal" style="margin-bottom:12.0pt">
Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - TCG Embedded Systems Hardcopy SG<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"><span style="color:#3333ff">http://sites.google.com/site/blueroofmusic</span></a><br>
<a href="http://sites.google.com/site/highnorthinc" target="_blank"><span style="color:#6600cc">http://sites.google.com/site/highnorthinc</span></a><br>mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
Winter  579 Park Place  Saline, MI  48176  <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>Summer  PO Box 221  Grand Marais, MI 49839  <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><u></u><u></u></p>
</div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><p class="MsoNormal">On Sat, Jul 6, 2013 at 1:49 PM, William A Wagner &lt;<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>&gt; wrote:<u></u><u></u></p>
<div><div><p class="MsoNormal"><span style="color:#1f497d">Paul and WG,</span><u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d">From </span>PWG 5105.1-2004 PWG Semantic Model  (the initial print service model), constraints appear to be range or maxlength for integers, and Type X Keyword for strings. There are a few other sting constraints including DateTime,  and Uri (?), Repertoire,, etc.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">I suggest that to list all of the elements in a separate section with their ‘constraints’ would be cumbersome.  Keyword values are already  listed and we could add type  ID to that listing. Numeric integer constraints (0:MAX, 1:MAX, MIN:MAX, Maxlength=1023, Maxlength=127, Maxlength=63, Maxlength=255, Maxlength=40)  seem to be of  a limited number of values, and could be addressed in the element tables with notes. Other strings could be identified in the description. <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">Note however that, with few a exceptions, this document does not define the non-complex elements; it provides a reference to their definition. So constraints for such elements may be helpful, but would not appear to be critical. These were not included in the MFD Model specification.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">I solicit comments from the rest of the SM Working Group.<u></u><u></u></p><p class="MsoNormal">Thanks.<u></u><u></u></p><p class="MsoNormal">Bill Wagner<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Paul Tykodi [mailto:<a href="mailto:ptykodi@tykodi.com" target="_blank">ptykodi@tykodi.com</a>] <br>
<b>Sent:</b> Wednesday, July 03, 2013 5:36 PM<br><b>To:</b> &#39;Michael Sweet&#39;; &#39;William A Wagner&#39;<br><b>Cc:</b> <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a><br><b>Subject:</b> RE: [MFD] Schema Element Table format for Imaging System Model Spec</span><u></u><u></u></p>
</div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Hi Bill,</span><u></u><u></u></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I prefer the last format as well.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">One of the things I just learned from Pete, when he was briefing me on what I need to know for validating the Schema diagrams in section 5 (System Configuration) of the draft SM 2.0 document, was that Inter-elemental Constraints cannot be shown in the XML and the text representation in the tables is used to describe the constraints.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I don’t know whether we might want to consider creating a specific section in the SM 2.0 document for describing the constraints or not.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Best Regards,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">/Paul</span><u></u><u></u></p>
<div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">--</span><u></u><u></u></p></div><p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">Paul Tykodi<br>
Principal Consultant<br>TCS - Tykodi Consulting Services LLC<br><br>Tel/Fax: <a href="tel:603-343-1820" target="_blank">603-343-1820</a><br>Mobile:  <a href="tel:603-866-0712" target="_blank">603-866-0712</a><br>E-mail:  <a href="mailto:ptykodi@tykodi.com" target="_blank">ptykodi@tykodi.com</a></span><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1f497d"><br>
</span><span style="font-size:10.0pt;font-family:&quot;Arial&quot;,&quot;sans-serif&quot;;color:#1f497d">WWW:  </span><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;color:#1f497d"><a href="http://www.tykodi.com/" target="_blank"><span style="font-family:&quot;Arial&quot;,&quot;sans-serif&quot;">http://www.tykodi.com</span></a></span><u></u><u></u></p>
<div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> <a href="mailto:mfd-bounces@pwg.org" target="_blank">mfd-bounces@pwg.org</a> [<a href="mailto:mfd-bounces@pwg.org" target="_blank">mailto:mfd-bounces@pwg.org</a>] <b>On Behalf Of </b>Michael Sweet<br>
<b>Sent:</b> Wednesday, July 03, 2013 4:43 PM<br><b>To:</b> William A Wagner<br><b>Cc:</b> <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a><br><b>Subject:</b> Re: [MFD] Schema Element Table format for Imaging System Model Spec</span><u></u><u></u></p>
</div></div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal">I prefer the last format (what was used in the MFD Common Semantics and Model)...<u></u><u></u></p><div><p class="MsoNormal"> <u></u><u></u></p><div>
<div><p class="MsoNormal">On 2013-07-03, at 4:12 PM, William A Wagner &lt;<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>&gt; wrote:<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12.0pt">
 <u></u><u></u></p><div><div style="margin-left:.25in"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">The Imaging System Semantics and Model V2 will include and update information from MFD Common Semantics and Model and  the previous Service specifications. Much of the contents of these documents consists of showing hierarchical Schema graphics followed by detailed descriptions of the elements in the diagram.  The earlier documents used three different approaches for these descriptions, as indicated in the discussion document posted at</span><u></u><u></u></p>
</div><div style="margin-left:.25in"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"><a href="ftp://ftp.pwg.org/pub/pwg/mfd/white/table_format_examples.pdf" target="_blank"><span style="color:purple">ftp://ftp.pwg.org/pub/pwg/mfd/white/table_format_examples.pdf</span></a></span><u></u><u></u></p>
</div><div style="margin-left:.25in"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Each approach had its proponents and detractors. The most common format was the single row per entry table used in the MFD Common Semantics and model.</span><u></u><u></u></p>
</div><div style="margin-left:.25in"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> </span><u></u><u></u></p></div><div style="margin-left:.25in"><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">The Imaging System document should  use a consistent approach for this explanation of schema elements. Although difficulty in implementing the format should be considered, it is also important that the approach be useful and effective in describing the schema.  The three formats are described to allow a working group consideration and decision, hopefully by the next Semantic Model WG conference call.</span><u></u><u></u></p>
</div><div style="margin-left:.25in"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Thanks,</span><u></u><u></u></p></div><div style="margin-left:.25in"><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;">Bill Wagne</span><u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:10.0pt;margin-left:.25in"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:&quot;Andale Mono&quot;,&quot;serif&quot;"><br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b><span style="color:purple">MailScanner</span></b></a>, and is <br>
believed to be clean. _______________________________________________<br>mfd mailing list<br><a href="mailto:mfd@pwg.org" target="_blank"><span style="color:purple">mfd@pwg.org</span></a><br><a href="https://www.pwg.org/mailman/listinfo/mfd" target="_blank"><span style="color:purple">https://www.pwg.org/mailman/listinfo/mfd</span></a></span><u></u><u></u></p>
</div></div><p class="MsoNormal"> <u></u><u></u></p><div><div><p class="MsoNormal"><span style="font-family:&quot;Andale Mono&quot;,&quot;serif&quot;">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</span><u></u><u></u></p>
</div></div><p class="MsoNormal"> <u></u><u></u></p></div><p class="MsoNormal"><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. <u></u><u></u></p></div></div></div><div><div><p class="MsoNormal"><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. <u></u><u></u></p></div></div></div><p class="MsoNormal" style="margin-bottom:12.0pt"><br>_______________________________________________<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><u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></blockquote></div>
<br></div>
<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.