<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:390730808;
mso-list-type:hybrid;
mso-list-template-ids:-1288257354 -1371503874 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-start-at:7;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span><span lang="EN-GB">Nobody has responded to my latest mail. Perhaps, people need full text. Let me try.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I like the proposal to replace markup consumer/producer with consuming/producing application. This seems to be more in line with Part 1, which talks a lot
about consumers and producers and defines both as applications. There is one clause in Part 1 that contains “markup consumer” and “markup producer” (18.2.10) and we may want to edit away that usage as part of DR 13-0009.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span>- Reformulate normative sentences on "markup consumer" as those on "MCE processor".<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I think “markup consumer” was used to refer to the application layer above the MCE processor, the consuming application that feeds and takes output from an
MCE processor.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span>Use "consuming application" and "producing application" in informative statements and nowhere else<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Not sure we need to make them informative only since they do exist, provide context and are discussed frequently in Part 1. But if the intention is to strictly
scope the text in Part 3 only to the world of the MCE processor and avoid discussing anything outside that, then I agree with your assertion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">> Murata-san: “</span><span lang="EN-GB">We require that MCE processors copy application-defined elements (together with their attributes and contents) from
the input to the output.</span><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> ”</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">> Francis: “</span><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">such specifications must specify how such mechanisms
are to be handled by MCE processors.”</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Is there potential conflict here? It seems reasonable for the MCE processor to emit extensions (unprocessed). Francis’ also seems right if I think about it
from the perspective of the consuming application (e.g., does a consumer ignore non-understood extensions, preserve or discard on save, pass understood extensions back into a MCE processor, etc.). But from the perspective of an MCE processor, does Francis’
statement mean that the markup specification using MCE might require a MCE processor to process extensions or to not emit them (unprocessed)?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">>
</span><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Maybe we can agree that Part 3 only has to support the first case, but I think it is worth some discussion.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The first case is the way I interpret the existing text: MCE processing is suspended within extensions, Part 3 makes no requirements on how it is used within
a markup specification.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> Francis Cave [mailto:francis@franciscave.com]
<br>
<b>Sent:</b> Wednesday, August 21, 2013 5:43 AM<br>
<b>To:</b> 'SC 34/WG 4 mailing list'<br>
<b>Subject:</b> RE: Proposed text for Clause 9<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Sorry, I tried to draft a response, but in the end I didn’t think it was a useful contribution so I didn’t send it.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree that the terminology currently is causing some confusion, especially the term “markup consumer”. I think I agree that we only need “MCE
processor” as a formally-defined term and that “consuming application” and “producing application” don’t need to be formally defined, but would like to hear the views of others on this.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I agree with Murata-san’s two principles. However, I suggest a third:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If markup specifications that apply MCE use additional extensibility mechanisms, such as extension elements, such specifications must
specify how such mechanisms are to be handled by MCE processors.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thinking about this, I can imagine that different markup specifications might (theoretically) specify a variety of interactions between MCE and
extension elements, i.e.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Use of MCE is allowed anywhere. MCE processors must not process the content of extension elements. (This is the OOXML case.)<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Use of MCE is only allowed within extension elements. MCE processors must (only) process the content of extension elements and either
ignore or treat as errors (mismatches?) MCE constructs that occur elsewhere. (This is a restricted case, where schema extension is only allowed within extension elements.)<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Use of MCE is only allowed within extension elements. MCE processors must process the content of some extension elements but not others.
(This is a combination of the first two cases.)<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Maybe we can agree that Part 3 only has to support the first case, but I think it is worth some discussion. I accept that the meaning of “extension
element” is different in the first case from in the other two cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Francis<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<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:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:eb2mmrt@gmail.com">eb2mmrt@gmail.com</a> [<a href="mailto:eb2mmrt@gmail.com">mailto:eb2mmrt@gmail.com</a>]
<b>On Behalf Of </b>MURATA Makoto<br>
<b>Sent:</b> 21 August 2013 12:12<br>
<b>To:</b> SC 34/WG 4 mailing list<br>
<b>Subject:</b> Re: Proposed text for Clause 9<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">Nobody has responded to my latest mail. Perhaps, people need <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">full text. Let me try.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Regards,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Makoto<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">2013/8/16 MURATA Makoto <<a href="mailto:eb2m-mrt@asahi-net.or.jp" target="_blank">eb2m-mrt@asahi-net.or.jp</a>><o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB">John and Francis,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">As I said during the teleconf, I think that the confusion stems <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">from non-clear separation of MCE processors and applications<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">in the current text. I am trying to clarify requirements on <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">MCE processors. Meanwhile Francis is trying to allow <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">some office suites NOT to preserve ext elements. (I agree<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">that such office suites should not be prohibited by 29500.)<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Here is what I would like to propose.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Principles<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- MCE processors are crucial in MCE, just like XML processors are <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> crucial in XML. Clearly define requirements on MCE processors.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- Consuming applications are built on top of MCE processors at least<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> conceptually. There should be no requirements on consuming <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> applications. Nothing prevents some office suite from discarding <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> ext elements in SML.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">General<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- The term "markup consumer" is considered misleading, since it makes it<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> difficult for us to separate MCE processors and consuming <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> applications.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- Drop "markup consumer" and "markup producer" from the Terms<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> and Definitions clause.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- Reformulate normative sentences on "markup consumer" <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> as those on "MCE processor".<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- Use "consuming application" and "producing application" in<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> informative statements and nowhere else. These are usual noun<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> phrases rather than terms defined in the Terms and Definitions<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> clause. These phrases are used only for providing a high-level <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> overview.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">- Unless there are mismatches or errors, MCE processors emit<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> output documents, as specified in the revised Part 3. We require<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> that MCE processors copy application-defined elements (together<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"> with their attributes and contents) from the input to the output.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">If people agree with the above approach, I will prepare replacement <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">text.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Regards,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-GB">Makoto<o:p></o:p></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB">2013/8/16 John Haug <<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB">I believe the current text implies that the MCE processor does nothing with them by saying that MCE processing is suspended within them - that it's just a pass-through as Murata-san mentioned. Whether they're preserved
in the output document it out of scope for that pass of the MCE processor. I believe thhis also matches our implementation - the MCE processor just hands them up to the calling markup consumer / application program, which decides whether to crack them open,
I believe by handing them to a MCE processor (if they're understood) or ignore them (if they're not understood) and choosing whether to discard or retain them for the next file save.<br>
<br>
At least, that's always been m understanding.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB"><br>
John<br>
<br>
-----Original Message-----<br>
From: Francis Cave [mailto:<a href="mailto:francis@franciscave.com" target="_blank">francis@franciscave.com</a>]<o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-GB">Sent: Thursday, August 15, 2013 1:53 PM<br>
To: 'SC 34/WG 4 mailing list'<br>
Subject: RE: Proposed text for Clause 9<br>
<br>
John<br>
<br>
The intent of my original text (which, you're right, I didn't copy to the WG list - apologies about that) was to avoid saying anything normative about the behaviour of MCE processors with respect to extension elements, as I felt it is a feature of OOXML as
a markup spec that extension elements should be untouched by MCE processors and not necessarily a required feature of all MCE applications. I think that Murata-san has convinced me - almost - that MCE processors should always leave extension elements untouched,
so that the application software part of the markup consumer can determine what to do with extension elements that it does or does not understand.<br>
<br>
Kind regards,<br>
<br>
Francis<br>
<br>
<br>
<br>
<br>
> -----Original Message-----<br>
> From: John Haug [mailto:<a href="mailto:johnhaug@exchange.microsoft.com" target="_blank">johnhaug@exchange.microsoft.com</a>]<br>
> Sent: 15 August 2013 21:34<br>
> To: 'SC 34/WG 4 mailing list'<br>
> Subject: RE: Proposed text for Clause 9<br>
><br>
> May I risk wading into this? I think I understand Murata-san's points<br>
> and<br>
I<br>
> think the general direction of his text is OK. But I also think<br>
> Francis<br>
has a<br>
> point about the way the language is used.<br>
><br>
> Re: the second paragraph:<br>
> I believe it ought not mention preservation, since that is an optional<br>
> function of the markup consumer. Murata-san pointed out that "MCE<br>
processors<br>
> simply pass application defined extension elements to application<br>
programs"<br>
> which is correct. But I agree with Francis that the language of the<br>
second<br>
> paragraph sounds like "extension elements shall be preserved in the<br>
> output document". May I suggest that the second paragraph be reformed<br>
> to simply point to section 10 for rules about how MCE processors<br>
> handle extension elements?<br>
><br>
> Re: Murata-san's follow-up comment:<br>
> > "recognise" in this context means "preserve".<br>
> Well, I meant that the markup configuration, which is a set of<br>
expanded<br>
> names, contain the expanded names of application-defined extension<br>
elements.<br>
> If that means the point of the second paragraph is to state the markup<br>
> configuration remains unchanged (not sure if that is the point), then<br>
> I'd suggest it's not necessary to state that since there is no<br>
> indication in<br>
the<br>
> text that the markup configuration would ever change.<br>
><br>
> Re: the last paragraph:<br>
> I suggest we make that a Note. It's good clarifying information worth<br>
making<br>
> clear that we consider it normal behavior. Even though the whole<br>
> clause 9<br>
is<br>
> informative, the statement is about something outside the scope of<br>
specifying<br>
> an MCE processor and I think it would make the intent that it's<br>
> ancillary information more clear by making it an explicit Note.<br>
><br>
> The only thing I can't evaluate is Francis' statement " Your proposed<br>
> text<br>
...<br>
> defines an extension element somewhat more narrowly than I had<br>
> proposed in<br>
my<br>
> draft text". I don't know what original draft text is referred to here.<br>
It<br>
> looks like Murata-san's text (and the relevant bits of clause 10)<br>
> mirrors<br>
what<br>
> is specified in the existing Part 3.<br>
><br>
> John<br>
><br>
><br>
> -----Original Message-----<br>
> From: Francis Cave [mailto:<a href="mailto:francis@franciscave.com" target="_blank">francis@franciscave.com</a>]<br>
> Sent: Tuesday, August 13, 2013 5:56 AM<br>
> To: 'SC 34/WG 4 mailing list'<br>
> Subject: RE: Proposed text for Clause 9<br>
><br>
> Murata-san<br>
><br>
> I understand the distinction between MCE processors and markup consumers.<br>
><br>
> > To me, markup consumers and MCE processors are very different.<br>
> > Requirements on MCE processors have to be very clear. Their<br>
> > behaviours<br>
> are<br>
> > complet[el]y predictable. But requirements on markup consumers are<br>
> > much<br>
> more<br>
> > predictable.<br>
><br>
> I think you mean that the requirements on markup consumers are much<br>
> LESS predictable.<br>
><br>
> But if the behaviours of MCE processors are completely predictable,<br>
> should these not be specified normatively somewhere? If the behaviour<br>
> of an MCE processor with respect to extension elements must be<br>
> completely<br>
predictable,<br>
> this behaviour must be specified normatively. Where is it to be specified?<br>
> Either in the MCE spec or in the markup spec.<br>
><br>
> I think that my confusion is between the specification of extension<br>
elements<br>
> (in the markup spec) and the specification of MCE processor behaviour<br>
> (in<br>
the<br>
> MCE spec). If we can completely specify MCE processor behaviour with<br>
respect<br>
> to extension elements, this should be done normatively in the MCE<br>
> spec. If<br>
we<br>
> cannot - i.e. it depends upon how the extension elements are specified<br>
> in<br>
the<br>
> markup spec - we cannot say anything normative about it in the MCE<br>
> spec<br>
and we<br>
> probably shouldn't make too many assumptions about it.<br>
><br>
> Kind regards,<br>
><br>
> Francis<br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: <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>] On Behalf Of<br>
> > MURATA<br>
> Makoto<br>
> > Sent: 13 August 2013 13:11<br>
> > To: SC 34/WG 4 mailing list<br>
> > Subject: Re: Proposed text for Clause 9<br>
> ><br>
> > Francis,<br>
> ><br>
> > Perhaps, the problem is the ambiguity in our terminology:<br>
> > markup consumer , MCE processor, and application program.<br>
> > We might want to make this point clear in Clause 7.<br>
> ><br>
> > > Your second paragraph says:<br>
> > ><br>
> > > "If an MCE processor is configured to recognise extension<br>
> > > elements, it preserves them together with their attributes and contents."<br>
> > ><br>
> > > I think what you are saying is that an MCE processor that is<br>
> > > configured to recognise extension elements will ALWAYS preserve them.<br>
> > > In other words,<br>
> ><br>
> > Exactly. But I am talking about the MCE processor. I am not<br>
> > talking<br>
> about<br>
> > markup consumers.<br>
> ><br>
> > > "recognise" in this context means "preserve".<br>
> ><br>
> > Well, I meant that the markup configuration, which is a set of<br>
> > expanded<br>
> names,<br>
> > contain the expanded names of application-defined extension elements.<br>
> ><br>
> > > If this is ALWAYS the case,<br>
> > > that sounds to me like a normative provision. If it is up to the<br>
> > > application to specify this (as I thought we had agreed), it may<br>
> > > not always be the case, in which we should not imply that in the MCE spec.<br>
> ><br>
> > To me, markup consumers and MCE processors are very different.<br>
> > Requirements on MCE processors have to be very clear. Their<br>
> > behaviours<br>
> are<br>
> > complety predictable. But requirements on markup consumers are much<br>
> > more predictable.<br>
> ><br>
> > Regards,<br>
> > Makoto<br>
> ><br>
> > ><br>
> > > Kind regards,<br>
> > ><br>
> > > Francis<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > >> -----Original Message-----<br>
> > >> From: <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>] On Behalf Of<br>
> > >> MURATA<br>
> > > Makoto<br>
> > >> Sent: 13 August 2013 11:12<br>
> > >> To: SC34<br>
> > >> Subject: Re: Proposed text for Clause 9<br>
> > >><br>
> > >> Francis,<br>
> > >><br>
> > >> > 1. Your proposed text (expecially the first sentence of the<br>
> > >> > second paragraph, and the final paragraph) defines an extension<br>
> > >> > element somewhat more narrowly than I had proposed in my draft<br>
> > >> > text. Yours is closer to what<br>
> > >><br>
> > >> I rather think that your wording states too much about<br>
> > >> application<br>
> > > programs.<br>
> > >> I think that we should limit our concern to behaviours of MCE<br>
> > >> processors<br>
> > > and<br>
> > >> try to avoid describing behaviours of application programs.<br>
> > >> MCE processors simply pass application defined extension elements<br>
> > >> to application programs. The behaviours of MCE processors have<br>
> > >> to be very<br>
> > > clear<br>
> > >> for interoperability.<br>
> > >><br>
> > >> > is currently in OOXML, which may be a good thing (it shouldn't<br>
> > >> > break any OOXML implementations), but I still wonder whether<br>
> > >> > the MCE spec should be quite so proscriptive about the<br>
> > >> > processing of extension elements or should instead leave it to<br>
> > >> > the markup specification to define how MCE processors should<br>
> > >> > handle extension elements in each specific case. Putting it<br>
> > >> > another way, your proposed Clause 9 seems to be saying<br>
> > >> > something normative about the processing of extension elements,<br>
> > >> > although you have made it clear in the Clause heading that the<br>
> > >> Clause is informative.<br>
> > >><br>
> > >> My 2nd para may look normative at a first glance, but it is not.<br>
> > >> It just gives a high-level overview without providing details.<br>
> > >> Details are<br>
> > > provided<br>
> > >> in the itemized lists in Steps 1 and 2.<br>
> > >><br>
> > >> ><br>
> > >> > 2. At the end of the second paragraph you have a<br>
> > >> > cross-reference to "Clause 9". This is self-referential, so<br>
> > >> > clearly wrong. What is<br>
> meant?<br>
> > >><br>
> > >><br>
> > >> Oops. Clause 10 Semantic Definitions and Reference Processing Model.<br>
> > >><br>
> > >> Regards,<br>
> > >> Makoto<br>
> > >><br>
> > >> > Kind regards,<br>
> > >> ><br>
> > >> > Francis<br>
> > >> ><br>
> > >> ><br>
> > >> ><br>
> > >> >> -----Original Message-----<br>
> > >> >> From: <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>] On Behalf<br>
> > >> >> Of MURATA<br>
> > >> > Makoto<br>
> > >> >> Sent: 13 August 2013 10:11<br>
> > >> >> To: SC34<br>
> > >> >> Subject: Proposed text for Clause 9<br>
> > >> >><br>
> > >> >> Dear colleagues,<br>
> > >> >><br>
> > >> >> Here is a proposed rewrite of Clause 9. It is based on Francis'<br>
> > >> >> wording<br>
> > >> > but<br>
> > >> >> has been modified and further expanded by two examples. Thanks.<br>
> > >> >> ><br>
> > >> > Francis.<br>
> > >> >><br>
> > >> >> Regards,<br>
> > >> >> Makoto<br>
> > >> >><br>
> > >> > ---------------------------------------------------------------<br>
> > >> > --<br>
> > >> > --<br>
> > >> > ---<br>
> > >> > ------<br>
> > >> > -<br>
> > >> >><br>
> > >> >> 9. Extension elements defined by a markup specification<br>
> > >> >> (informative)<br>
> > >> >><br>
> > >> >> A markup specification that uses Markup Compatibility elements<br>
> > >> >> and<br>
> > >> > attributes<br>
> > >> >> to allow extensions in namespaces other than those defined by<br>
> > >> >> the markup specification may also define one or more specific<br>
> > >> >> extension elements in<br>
> > >> > the<br>
> > >> >> namespaces that it defines. [Note: If the markup specification<br>
> > >> >> includes a schema, any extension elements would normally be<br>
> > >> >> constrained by the schema<br>
> > >> > to<br>
> > >> >> occur only in specific markup contexts. end note].<br>
> > >> >><br>
> > >> >> If an MCE processor is configured to recognise extension<br>
> > >> >> elements, it preserves them together with their attributes and<br>
> contents.<br>
> > >> >> See Clause 9<br>
> > >> > for<br>
> > >> >> details.<br>
> > >> >><br>
> > >> >><br>
> > >> >> [Example:<br>
> > >> >><br>
> > >> >><br>
> > >> > <a href="https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestDat" target="_blank">
https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestDat</a><br>
> > >> > a/<br>
> > >> > Ex<br>
> > >> > ten<br>
> > >> > sionEl<br>
> > >> > em<br>
> > >> >> ents/example1.xml<br>
> > >> >><br>
> > >> >> In this example, the e1:foo element contains the unknown:foo<br>
> element.<br>
> > >> >> Suppose that a markup configuration contains an expanded name<br>
> > >> >> ("<a href="http://www.example.com/e1" target="_blank">http://www.example.com/e1</a>", "foo") and that an application<br>
> > >> >> configuration does not contain "<a href="http://www.example.com/unknown" target="_blank">http://www.example.com/unknown</a>".<br>
> > >> >> Then, the element e1:foo is an application-defined extension<br>
> element.<br>
> > >> >> Although the unknown:foo element does not belong to an<br>
> > >> >> understood or<br>
> > >> > ignorable<br>
> > >> >> namespace, the MCE processor preserves it and does not report<br>
> > >> >> any<br>
> > > errors.<br>
> > >> > end<br>
> > >> >> example]<br>
> > >> >><br>
> > >> >> [Example:<br>
> > >> >><br>
> > >> >><br>
> > >> > <a href="https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestDat" target="_blank">
https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestDat</a><br>
> > >> > a/<br>
> > >> > Ex<br>
> > >> > ten<br>
> > >> > sionEl<br>
> > >> > em<br>
> > >> >> ents/example2.xml<br>
> > >> >><br>
> > >> >> In this example, Markup Compatibility elements and attributes<br>
> > >> >> occur within<br>
> > >> > the<br>
> > >> >> extensionElement element, which is the only child of the root<br>
> > >> >> element<br>
> > >> > example.<br>
> > >> >> Suppose that a markup configuration contains an expanded name<br>
> > >> >> ("<a href="http://www.example.com/e1" target="_blank">http://www.example.com/e1</a>", "extensionElement").<br>
> > >> >> Then, the MCE processor preserves the extensionElement element.<br>
> > >> >> Therefore, MCE elements and attributes within it, namely<br>
> > >> > mce:Ignorable="i1",<br>
> > >> >> mce:ProcessContent="i1:bar1", mce:MustUnderstand="e1",<br>
> > >> > mce:AlternateConent,<br>
> > >> >> mce:Choice, and mce:Fallback, appear in the output document.<br>
> > >> >> end example]<br>
> > >> >><br>
> > >> >> After receiving the output of an MCE processor, application<br>
> > >> >> programs may further invoke an MCE processor to handle Markup<br>
> > >> >> Compatibility elements<br>
> > >> > and<br>
> > >> >> attributes within extension elements.<br>
> > >> ><br>
> > >><br>
> > >><br>
> > >><br>
> > >> --<br>
> > >><br>
> > >> Praying for the victims of the Japan Tohoku earthquake<br>
> > >><br>
> > >> Makoto<br>
> > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> ><br>
> > Praying for the victims of the Japan Tohoku earthquake<br>
> ><br>
> > Makoto<o:p></o:p></span></p>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><br>
<br clear="all">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB">-- <br>
<br>
Praying for the victims of the Japan Tohoku earthquake<br>
<br>
Makoto <o:p></o:p></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span lang="EN-GB"><br>
<br clear="all">
<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-GB"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-GB">-- <br>
<br>
Praying for the victims of the Japan Tohoku earthquake<br>
<br>
Makoto <o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>