<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/8/13 Francis Cave <span dir="ltr"><<a href="mailto:francis@franciscave.com" target="_blank">francis@franciscave.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">
Murata-san<br>
<br>
I understand the distinction between MCE processors and markup consumers.<br>
<div class="im"><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>
</div>> 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.<br>
<br></blockquote><div><br></div><div>Right.</div><div> </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">
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.<br>
<br></blockquote><div>At present, the behaviour of MCE processors for application-defined </div><div>extension elements is normative defined in several places:</div><div><br></div><div> - the 4th bullet in the 1st itemized list in Step 1 in Clause 9</div>
- 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</div>
<div class="gmail_quote"> - The 1st, 2nd, and 3rd paragraphs in Step 4 in Clause 9<br><div> </div><div>Regards,</div><div>Makoto</div><div><br></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">
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.<br>
<div class="im"><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<br>
</div><div class=""><div class="h5">> 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<br>
<br>
</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>