<div dir="ltr">Caroline,<div><br></div><div>Thank you for your careful reviewing!<br><div class="gmail_extra"><br><div class="gmail_quote">2018-01-21 5:53 GMT+09:00 caroline arms <span dir="ltr"><<a href="mailto:caroline.arms@gmail.com" target="_blank">caroline.arms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div>Murata-san, Rex, et al.<br><br></div>I have started to go through the draft.  Rather than wait to the teleconference, I thought I would send emails on issues that are not simply fixing typos or grammar as I come across them.  <br><br>Clause §8.3.5 includes<br>"The path components are equivalent part names, as specified in §8.2.2 [M7.3]"<br><br>Should this point instead to §8.2.2.3 Part Name Equivalence and Integrity in a Package?<br></div></div></div></blockquote><div><br></div><div>"equivalent" is defined in 8.2.2.3, but "part names" is defined </div><div>in  8.2.2.1 and 8.2.2.2.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br>I find §8.2.2.3 rather confusing and as I read it carefully, I realized that "equivalence" as meant in §8.3.5 might need to incorporate more than ASCII case-insensitive matching -- as equivalence is defined in the first paragraph of §8.2.2.3.  In particular, I wondered whether equivalence after application of NFC was also relevant.  <br></div></div></div></blockquote><div><br></div><div>No, they are not.  Microsoft never does NFC to part names.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br>Perhaps someone more expert than me can weigh in here.<br><br>I realize that §8.2.2.3 mixes "shall" and "should" -- presumably deliberately.  That probably adds complexity here.<br></div></div></div></blockquote><div><br></div><div>Yes, it is confusing.  But I believe that Microsoft and Apple do different </div><div>things here.  Microsoft never normalizes file names.  Apple always </div><div>does.  Part name crashes by Apple (and possibly others) should </div><div>be avoided.  That's why we have a number of "should" in 8.2.2.3.</div><div><br></div><div>Regards,</div><div>Makoto</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br>I have some other concerns about §8.2.2.3, but I would need clarification on what "equivalence" needs to be for §8.3.5 before I could make useful suggestions.<br><br></div>    Caroline<br><br></div>PS:  Given the government shutdown, please be sure to send important emails to my gmail account (or to the WG4 list).  I'm afraid the shutdown may play havoc with my schedule, just as the threat of a shutdown has been leading to inefficiency over the last few weeks.<br><div><div><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 9, 2018 at 3:46 PM, Rex Jaeschke <span dir="ltr"><<a href="mailto:rex@rexjaeschke.com" target="_blank">rex@rexjaeschke.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-2586343505769044150gmail-m_1789019331301166543WordSection1"><p class="MsoNormal">Attached is WD3.3 of the OPC Spec.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Once I got it back from Murata-san, here’s what I did:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><ol style="margin-top:0in" start="1" type="1"><li class="gmail-m_-2586343505769044150gmail-m_1789019331301166543MsoListParagraph" style="margin-left:0in">I adopted all edits from WD3.2 and prior that had been resolved, so they no longer show as tracked changes.<u></u><u></u></li><li class="gmail-m_-2586343505769044150gmail-m_1789019331301166543MsoListParagraph" style="margin-left:0in">I kept all the comments that do not appear to have been resolved.<u></u><u></u></li><li class="gmail-m_-2586343505769044150gmail-m_1789019331301166543MsoListParagraph" style="margin-left:0in">All Murata-san’s edits proposed since WD3.2 are shown as tracked changes.<u></u><u></u></li></ol><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I propose that at the March F2F meeting, we walk through this document and accept/reject the proposed edits, and resolve the issues raised in comments.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Our most-recent discussion of a time line for this spec was to have a complete version at the end of the March 2018 meeting, and after minor changes from the F2F meeitng, to send it out for a 2-month CD ballot, closing before the June F2F. I now think this is quite unrealistic. There is a lot of work to do yet, and the decisions we make in March will need to be applied to the spec and then reviewed in the following teleconferences. We migth have a shot at getting a near-final draft for review of the June meeting.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Murata-san has long pushed to get rid of informative Annex <a name="m_-2586343505769044150_m_1789019331301166543__Ref194213939">G </a><span>[formerly H]<a name="m_-2586343505769044150_m_1789019331301166543__Toc379265880"></a><a name="m_-2586343505769044150_m_1789019331301166543__Toc385397170"></a><a name="m_-2586343505769044150_m_1789019331301166543__Toc391632752"></a><a name="m_-2586343505769044150_m_1789019331301166543__Toc503272968"><span><span><span>, “Guidelines for Meeting Conformance</span></span></span></a></span>”, while I pushed for keeping it. And while we agreed to keep it, it still needed serious work to make it complete. Unfortunately, in its current state, many of its links and bookmarks are now badly broken, and will be non-trivial to reconstruct. So, reluctantly, I am dropping my objection to removing this Annex. As such, I have *<b>not</b>* done any work on repairing/updating this annex. If we drop this annex, we’ll need to decide what to do about all the [M], [O], and [S] markers spread throughout the normative text.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">In DR 13-0002, Murata-san proposed the addition of a new informative Annex, “Guidelines for Format Designers” (see <a href="https://goo.gl/gzIX9y)" target="_blank">https://goo.gl/gzIX9y)</a>”. As I cannot access this link, I have not added this annex. Murata-san, can you please circulate this proposed text?<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As Caroline will likely not attend the March meeting, I’d like to give her time to review and submit feedback before then. Likewise for Aarti’s experts (who likely will not attend that meeting).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">We’ll have a big job in March resolving all the open issues, so the more preparation you can do before then, the better. And, of course, we can do serious work on this on our January 31 teleconference.<span class="gmail-m_-2586343505769044150gmail-HOEnZb"><font color="#888888"><u></u><u></u></font></span></p><span class="gmail-m_-2586343505769044150gmail-HOEnZb"><font color="#888888"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Rex<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p></font></span></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div></div></div>