<div dir="ltr">I created a proposed rewrite. Unlike the first CD, no MCE constructs are used. <div>Rather, OPC parts are used heavily.</div><div><br></div><div>Regards,</div><div>Makoto<br><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-07 19:21 GMT+09:00 MURATA Makoto <span dir="ltr"><<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Dear colleagues,</div><div><br></div><div>I think that we should rely on additional OPC parts rather than </div><div>app-defined ext elems or MCE.</div><div><br></div><div>The rest of this mail describes an alternative to the first CD. </div><div>The idea is very simple. Introduce an empty part as the origin </div><div>of character checking. From this empty part, reference a</div><div>Character Checking Condition part. It references another <br></div><div>part, which is the target of character checking, and also </div><div>specifies a CREPDL script (19757-7). Since I used OPC </div><div>digital signature as a basis, I used an attribute for referencing </div><div>the target part. But we might want to rely on relationships.</div><div><br></div><div><br></div><div><br></div><div>5.1 General</div><div><br></div><div>The character chedking parts consist of the Character Checking Origin</div><div>part and Character Checking Condition parts. Relationship names and</div><div>content types relating to the use of digital signatures in packages</div><div>are defined in Annex E.</div><div><br></div><div>Figure X–X shows a package with the Character Checking Origin part and</div><div>two Character Checking Condition parts. The example Character</div><div>Checking Origin part references two Character Checking Condition</div><div>parts, each containing a CREPDL script.</div><div><br></div><div>Editor's Note: This figure is very similar to Figure 12–1 in Part 2. </div><div><br></div><div>5.2 Character Checking Condition part</div><div><br></div><div>A Character Checking Condition part has a Reference, Location, and a</div><div>Condition element in this sequence.</div><div><br></div><div>5.2.1 Reference element</div><div><br></div><div>Note: This is similar to the Reference element in OPC.</div><div><br></div><div><Reference URI="/document.xml?ContentType=application/ </div><div> vnd.ms-document+xml"> </div><div><br></div><div>5.2.2 Location element </div><div><br></div><div>A location element optionally specifies locations in the referenced</div><div>part. Character contents at the specified location are subject to</div><div>character checking.</div><div><br></div><div>At present, a location element has no elements and attributes, and</div><div>is assumed to specify the entire part.</div><div><br></div><div>5.2.3 Condition element </div><div><br></div><div>A Condition element has a CREDPL script as defined in ISO/IEC 19757-7</div><div>as the only child element.</div><div><br></div><div>5.2.4 Processing model</div><div><br></div><div>Visit each Character Checking Condition part in sequence. Check</div><div>the character content at the specified location against the </div><div>CREPDL script in the Condition element.</div><div><br></div><div>Annex A (normative) Schemas - W3C XML Schema</div><div><br></div><div>Annex B (informative) Schemas - RELAX NG</div><div><br></div><div>Annex C (normative) Standard Namespaces, Content Types , and Relationship Types</div><div><br></div><div>C.1 Namespaces</div><div><br></div><div><a href="http://schemas.openxmlformats.org/officeDocumentExtension/2015/characterCheckingConstraint" target="_blank">http://schemas.openxmlformats.org/officeDocumentExtension/2015/characterCheckingConstraint</a></div><div><br></div><div>CREPDL</div><div><br></div><div>C.2 Content Types</div><div><br></div><div>Character Checking Conndition part application/vnd.openxmlformats-extension.character-checking-condition</div><div><br></div><div>Character Checking Origin part application/vnd.openxmlformats-extension.character-checking-origin</div><div><br></div><div>C.3 Relationshp Type</div><div><br></div><div><a href="http://schemas.openxmlformats.org/officeDocumentExtension/relationships/2015/characterCheckingConstraint" target="_blank">http://schemas.openxmlformats.org/officeDocumentExtension/relationships/2015/characterCheckingConstraint</a></div><div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div>Regards,</div><div>Makoto</div><div><div class="h5"><div><br></div><div><br></div><div class="gmail_quote">2014-12-14 5:32 GMT+09:00 MURATA Makoto <span dir="ltr"><<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</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 dir="ltr">Francis,<div><br></div><div>We discussed your experiment (thanks!) in the last teleconf. Here is my note</div><div><br></div><div><div style="font-size:14.3999996185303px"><div>There was a discussion about custom metadata. Francis Cave reported</div><div>that some implementations do not preserve custom metadata parts even</div><div>if they are referenced by package relationships. We considered the</div><div>use of MCE for representing custom metadata, but we find that "11.3</div><div>Support for Versioning and Extensibility" in 29500-2 prohibits such</div><div>use. Rather, this subclause recommends "creating a new part and using</div><div>a relationship with a new type to point from the Core Properties part</div><div>to the new part". We thus agreed (1) to use a relationship from the</div><div>Core Properties part to a custom metadata part, and (2) to introduce a</div><div>note for preserving valid relationships as well as targets of such</div><div>relationships.</div><div><br></div><div><br></div><div>Regards,</div><div>Makoto</div><div><br></div></div></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">2014-12-14 0:49 GMT+09:00 Francis Cave <span dir="ltr"><<a href="mailto:francis@franciscave.com" target="_blank">francis@franciscave.com</a>></span>:<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-GB" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">If you remember, I experimented with adding foreign OPC parts to hold ONIX metadata. Recent versions of MS Office don’t appear to throw away such foreign parts, but the version of LIbreOffice that I tested does appear to throw them away.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Nevertheless, I think we should explore the idea of using a foreign OPC part for character repertoire checking data, as this avoids the need to embed such data in content. I prefer this approach to the use of application-defined extension elements or ignorable elements. As you say, so far as implementations of the existing standard are concerned, new application-defined extension elements would have to be in ignorable namespaces, otherwise the implementations would be broken.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Regards,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Francis<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif"> <a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com" target="_blank">eb2mmrt@gmail.com</a>] <b>On Behalf Of </b>MURATA Makoto<br><b>Sent:</b> 13 December 2014 08:32<br><b>To:</b> SC34<br><b>Subject:</b> 30114-2: ignorables, app-defined ext elems, or custom OPC parts<u></u><u></u></span></p><div><div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Summary: Avoid ignorable elements but use application-defined<u></u><u></u></p></div><div><p class="MsoNormal">extension elements or additional OPC parts instead.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I have thought that we should use ignorable elements for representing<u></u><u></u></p></div><div><p class="MsoNormal">data for character repertoire checking. The first CD does use them.<u></u><u></u></p></div><div><p class="MsoNormal">This approach is easy to standardize and implement, but existing<u></u><u></u></p></div><div><p class="MsoNormal">implementations will surely throw away data for character repertoire<u></u><u></u></p></div><div><p class="MsoNormal">checking. I have stupidly thought that this is OK. But no users are<u></u><u></u></p></div><div><p class="MsoNormal">willing to use what is thrown away by existing MS Office and Libre<u></u><u></u></p></div><div><p class="MsoNormal">Office.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The use of application-defined extension elements ensures that data<u></u><u></u></p></div><div><p class="MsoNormal">for character repertoire checking is preserved. But locations of<u></u><u></u></p></div><div><p class="MsoNormal">application-defined extension elements are already set in stone, and<u></u><u></u></p></div><div><p class="MsoNormal">cannot be changed without making existing implementations<u></u><u></u></p></div><div><p class="MsoNormal">non-conformant.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Another option is to use additional OPC parts. If implementations do<u></u><u></u></p></div><div><p class="MsoNormal">not throw away targets of valid relationships, data for character<u></u><u></u></p></div><div><p class="MsoNormal">repertoire checking is preserved.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I can imagine that the use of additional OPC parts has its own<u></u><u></u></p></div><div><p class="MsoNormal">problems. But we should try seriously.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Regards,<u></u><u></u></p></div><div><p class="MsoNormal">Makoto<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div></div></blockquote></div><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</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>