<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-12 4:47 GMT+09:00 John Haug <span dir="ltr"><<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal">For Tuesday’s call.  We received more information this past week on the questions I asked.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">1. Regarding steps 1-9 in A.3: They said that the examples in A.4 should illustrate why the steps exist.  For example, see the line for the Unicode string “\a.xml” (4^th from bottom).  Without those steps (in particular, 4 and
 5), the result would be “/%5Ca.xml” rather than “/a.xml” because the URI that is run through those steps is “%5Ca.xml”.</p></div></div></blockquote><div><br></div><div>It appears that the biggest reason for the itemized list  is to </div>
<div>convert "\a.xml" to "/a.xml" automatically.   We have to do </div><div>that conversion.</div><div><br></div><div>I think that this conversion should be done as part of </div><div>the semantics of the pack scheme, rather than </div>
<div>by the resolution of relative references.  </div><div><br></div><div>But wait!  Are "/a.xml" and "\a.xml" equivalent? </div><div>If so, equivalent as part names or equivalent as </div><div>relative references (in that case, is "/./a.xml" </div>
<div>also equivalent?).</div><div><br></div><div>Regards,</div><div>Makoto</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">2. Regarding the text in subclause 9.2.1 (Relative References), “Relative references from a part are interpreted relative to the base URI of that part. By default, the base URI of a part is derived from the name of the part, as defined
 in §B.3.”: This is the output of step 6 in B.3.  They suggested that the following might make it more clear: “…the base URI of that part, which in this case is the URI of that part.”  I believe the crux is “the base URI *of that part*.”  All six steps in B.3
 are required to create a pack URI for the package *and a part*.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">3. Regarding the text in subclause 9.3.2.2 (Relationship Element), TargetMode attribute, “For package relationships, the package implementer shall resolve relative references in the Target attribute against the pack URI that identifies
 the entire package resource. [M1.29] For more information, see Annex B.”: This is the output of step 5 in B.3.  That output does not contain a part name embedded in the pack URI and thus is the pack URI for the entire package.  (The steps in B.3 open with
 “<span style="font-family:Constantia,serif">To compose a pack URI from the absolute package URI *and a part name*, the following steps shall be performed</span>”.)<span class=""><font color="#888888"><u></u><u></u></font></span></p>
<span class=""><font color="#888888">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">John<u></u><u></u></p>
</font></span></div>
</div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto
</div></div>