<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 12 (filtered medium)"><style><!--
/* Font Definitions */
@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:0cm;
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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></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-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sorry, Murata-san, I should have read the current working draft more carefully. <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'>So, the behaviour of MCE processors with respect to extension elements is currently defined as part of the processing model in Clause 9. If we accept that ALL applications of MCE must handle extension elements as currently specified in Clause 9, this is the right place to specify such normative behaviour. If, on the other hand, we can agree that SOME applications of MCE (not OOXML) might wish to specify different behaviours for MCE processors with respect to extension elements, we either have to remove such normative requirements from Clause 9, or make it clear that they are not mandatory but are recommended as likely best practice, or weaken them further by including them purely as examples of how MCE processors might behave. <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'>As I have already stated, my main concern is that, if we are revising Part 3 so that MCE can be applied in markup specifications other than OOXML, we should think carefully about which behaviours need to be normative for all MCE processors, regardless of MCE application, and which should be specified by the application. Clearly it makes sense to specify normatively all behaviours with respect to MCE constructs, i.e. constructs that are represented by elements and attributes with names in the MCE namespace. But I don’t think this necessarily applies to extension elements – which are, after all, supposed to be “application-defined”. I think it can be argued that if they are application-defined, the way they should be handled by MCE processors should also be application-defined. Otherwise, why not define an element in the MCE namespace called ‘mce:extension-element’ (or ‘mce:ext’, if you prefer) and leave it at that? I know that OOXML hasn’t done that, and maybe we feel that it should have done, but it didn’t, and therefore the question has arisen – in my mind, at least.<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'>Kind regards,<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'>Francis<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><p class=MsoNormal><span 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:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> eb2mmrt@gmail.com [mailto:eb2mmrt@gmail.com] <b>On Behalf Of </b>MURATA Makoto<br><b>Sent:</b> 22 August 2013 16:19<br><b>To:</b> Francis Cave<br><b>Cc:</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><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>2013/8/13 Francis Cave <<a href="mailto:francis@franciscave.com" target="_blank">francis@franciscave.com</a>><o:p></o:p></p><p class=MsoNormal>Murata-san<br><br>I understand the distinction between MCE processors and markup consumers.<o:p></o:p></p><div><p class=MsoNormal><br>> To me, markup consumers and MCE processors are very different.<br>> Requirements on MCE processors have to be very clear. Their behaviours<br>are<o:p></o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'>> complet[el]y predictable. But requirements on markup consumers are much<br>more<br>> predictable.<br><br>I think you mean that the requirements on markup consumers are much LESS<br>predictable.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Right.<o:p></o:p></p></div><div><p class=MsoNormal> <o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal style='margin-bottom:12.0pt'>But if the behaviours of MCE processors are completely predictable, should<br>these not be specified normatively somewhere? If the behaviour of an MCE<br>processor with respect to extension elements must be completely 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.<o:p></o:p></p></blockquote><div><p class=MsoNormal>At present, the behaviour of MCE processors for application-defined <o:p></o:p></p></div><div><p class=MsoNormal>extension elements is normative defined in several places:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal> - the 4th bullet in the 1st itemized list in Step 1 in Clause 9<o:p></o:p></p></div><p class=MsoNormal> - the 3rd bullet in the 2nd itemized list in Step 1 in Clause 9<br> - the 4rd bullet in the 3rd itemized list in Step 1 in Clause 9<br> - the 3rd bullet in the 1st itemized list in Step 2 in Clause 9<br> - the 2nd bullet in the 2nd itemized list in Step 2 in Clause 9<o:p></o:p></p></div><div><p class=MsoNormal> - The 1st, 2nd, and 3rd paragraphs in Step 4 in Clause 9<o:p></o:p></p><div><p class=MsoNormal> <o:p></o:p></p></div><div><p class=MsoNormal>Regards,<o:p></o:p></p></div><div><p class=MsoNormal>Makoto<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>I think that my confusion is between the specification of extension elements<br>(in the markup spec) and the specification of MCE processor behaviour (in<br>the MCE spec). If we can completely specify MCE processor behaviour with<br>respect to extension elements, this should be done normatively in the MCE<br>spec. If we cannot - i.e. it depends upon how the extension elements are<br>specified in the markup spec - we cannot say anything normative about it in<br>the MCE spec and we probably shouldn't make too many assumptions about it.<o:p></o:p></p><div><p class=MsoNormal><br>Kind regards,<br><br>Francis<br><br><br><br>> -----Original Message-----<br>> From: <a href="mailto:eb2mmrt@gmail.com">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com">eb2mmrt@gmail.com</a>] On Behalf Of MURATA<br>Makoto<o:p></o:p></p></div><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>> 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 elements, it<br>> > 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 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 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 not<br>> > 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 behaviours<br>are<br>> complety predictable. But requirements on markup consumers are much more<br>> 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">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com">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 second<br>> >> > paragraph, and the final paragraph) defines an extension element<br>> >> > somewhat more narrowly than I had proposed in my draft text. Yours<br>> >> > is closer to what<br>> >><br>> >> I rather think that your wording states too much about 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 to<br>> >> application programs. The behaviours of MCE processors have to be<br>> >> 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 the<br>> >> > MCE spec should be quite so proscriptive about the processing of<br>> >> > extension elements or should instead leave it to the markup<br>> >> > specification to define how MCE processors should handle extension<br>> >> > elements in each specific case. Putting it another way, your<br>> >> > proposed Clause 9 seems to be saying something normative about the<br>> >> > processing of extension elements, although you have made it clear<br>> >> > 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. It<br>> >> just gives a high-level overview without providing details. Details<br>> >> 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 cross-reference to<br>> >> > "Clause 9". This is self-referential, so 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">eb2mmrt@gmail.com</a> [mailto:<a href="mailto:eb2mmrt@gmail.com">eb2mmrt@gmail.com</a>] On Behalf Of<br>> >> >> 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>> >> > Francis.<br>> >> >><br>> >> >> Regards,<br>> >> >> Makoto<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 and<br>> >> > attributes<br>> >> >> to allow extensions in namespaces other than those defined by the<br>> >> >> 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 elements,<br>> >> >> it preserves them together with their attributes and 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/TestData/Ex" target="_blank">https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex</a><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 understood<br>> >> >> or<br>> >> > ignorable<br>> >> >> namespace, the MCE processor preserves it and does not report any<br>> > errors.<br>> >> > end<br>> >> >> example]<br>> >> >><br>> >> >> [Example:<br>> >> >><br>> >> >><br>> >> > <a href="https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex" target="_blank">https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex</a><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. end<br>> >> >> 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></p></div></div></blockquote></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <br><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto <o:p></o:p></p></div></div></div></div></body></html>