Proposed text for Clause 9

[MURATA Makoto]

2013/8/13 Francis Cave <francis at franciscave.com>

> Murata-san
>
> I understand the distinction between MCE processors and markup consumers.
>
> > To me, markup consumers and MCE processors are very different.
> > Requirements on MCE processors have to be very clear.  Their behaviours
> are
> > complet[el]y predictable.  But requirements on markup consumers are much
> more
> > predictable.
>
> I think you mean that the requirements on markup consumers are much LESS
> predictable.
>
>
Right.


> But if the behaviours of MCE processors are completely predictable, should
> these not be specified normatively somewhere? If the behaviour of an MCE
> processor with respect to extension elements must be completely
> predictable,
> this behaviour must be specified normatively. Where is it to be specified?
> Either in the MCE spec or in the markup spec.
>
> At present, the behaviour of MCE processors for application-defined
extension elements is normative defined in several places:

  - the 4th bullet in the 1st itemized list in Step 1 in Clause 9
  - the 3rd bullet in the 2nd itemized list in Step 1 in Clause 9
  - the 4rd bullet in the 3rd itemized list in Step 1 in Clause 9
  - the 3rd bullet in the 1st itemized list in Step 2 in Clause 9
  - the 2nd bullet in the 2nd itemized list in Step 2 in Clause 9
  - The 1st, 2nd, and 3rd paragraphs in Step 4 in Clause 9

Regards,
Makoto

I think that my confusion is between the specification of extension elements
> (in the markup spec) and the specification of MCE processor behaviour (in
> the MCE spec). If we can completely specify MCE processor behaviour with
> respect to extension elements, this should be done normatively in the MCE
> spec. If we cannot - i.e. it depends upon how the extension elements are
> specified in the markup spec - we cannot say anything normative about it in
> the MCE spec and we probably shouldn't make too many assumptions about it.
>
> Kind regards,
>
> Francis
>
>
>
> > -----Original Message-----
> > From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA
> Makoto
> > Sent: 13 August 2013 13:11
> > To: SC 34/WG 4 mailing list
> > Subject: Re: Proposed text for Clause 9
> >
> > Francis,
> >
> > Perhaps, the problem is the ambiguity in our terminology:
> > markup consumer , MCE processor, and application program.
> > We might want to make this point clear in Clause 7.
> >
> > > Your second paragraph says:
> > >
> > > "If an MCE processor is configured to recognise extension elements, it
> > > preserves them together with their attributes and contents."
> > >
> > > I think what you are saying is that an MCE processor that is
> > > configured to recognise extension elements will ALWAYS preserve them.
> > > In other words,
> >
> > Exactly.  But I am talking about the MCE processor.  I am not talking
> about
> > markup consumers.
> >
> > > "recognise" in this context means "preserve".
> >
> > Well, I meant that the markup configuration, which is a set of expanded
> names,
> > contain the expanded names of application-defined extension elements.
> >
> > > If this is ALWAYS the case,
> > > that sounds to me like a normative provision. If it is up to the
> > > application to specify this (as I thought we had agreed), it may not
> > > always be the case, in which we should not imply that in the MCE spec.
> >
> > To me, markup consumers and MCE processors are very different.
> > Requirements on MCE processors have to be very clear.  Their behaviours
> are
> > complety predictable.  But requirements on markup consumers are much more
> > predictable.
> >
> > Regards,
> > Makoto
> >
> > >
> > > Kind regards,
> > >
> > > Francis
> > >
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
> > >> MURATA
> > > Makoto
> > >> Sent: 13 August 2013 11:12
> > >> To: SC34
> > >> Subject: Re: Proposed text for Clause 9
> > >>
> > >> Francis,
> > >>
> > >> > 1. Your proposed text (expecially the first sentence of the second
> > >> > paragraph, and the final paragraph) defines an extension element
> > >> > somewhat more narrowly than I had proposed in my draft text. Yours
> > >> > is closer to what
> > >>
> > >> I rather think that your wording states too much about application
> > > programs.
> > >> I think that we should limit our concern to behaviours of MCE
> > >> processors
> > > and
> > >> try to avoid describing behaviours of application programs.
> > >> MCE processors simply pass application defined extension elements to
> > >> application programs.  The behaviours of MCE processors have to be
> > >> very
> > > clear
> > >> for interoperability.
> > >>
> > >> > is currently in OOXML, which may be a good thing (it shouldn't
> > >> > break any OOXML implementations), but I still wonder whether the
> > >> > MCE spec should be quite so proscriptive about the processing of
> > >> > extension elements or should instead leave it to the markup
> > >> > specification to define how MCE processors should handle extension
> > >> > elements in each specific case. Putting it another way, your
> > >> > proposed Clause 9 seems to be saying something normative about the
> > >> > processing of extension elements, although you have made it clear
> > >> > in the Clause heading that the
> > >> Clause is informative.
> > >>
> > >> My 2nd para may look normative at a first glance, but it is not.  It
> > >> just gives a high-level overview without providing details.  Details
> > >> are
> > > provided
> > >> in the itemized lists in Steps 1 and 2.
> > >>
> > >> >
> > >> > 2. At the end of the second paragraph you have a cross-reference to
> > >> > "Clause 9". This is self-referential, so clearly wrong. What is
> meant?
> > >>
> > >>
> > >> Oops.  Clause 10 Semantic Definitions and Reference Processing Model.
> > >>
> > >> Regards,
> > >> Makoto
> > >>
> > >> > Kind regards,
> > >> >
> > >> > Francis
> > >> >
> > >> >
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of
> > >> >> MURATA
> > >> > Makoto
> > >> >> Sent: 13 August 2013 10:11
> > >> >> To: SC34
> > >> >> Subject: Proposed text for Clause 9
> > >> >>
> > >> >> Dear colleagues,
> > >> >>
> > >> >> Here is a proposed rewrite of Clause 9.  It is based on Francis'
> > >> >> wording
> > >> > but
> > >> >> has been modified and further expanded by two examples.  Thanks. >
> > >> > Francis.
> > >> >>
> > >> >> Regards,
> > >> >> Makoto
> > >> >>
> > >> > -------------------------------------------------------------------
> > >> > ---
> > >> > ------
> > >> > -
> > >> >>
> > >> >> 9. Extension elements defined by a markup specification
> > >> >> (informative)
> > >> >>
> > >> >> A markup specification that uses Markup Compatibility elements and
> > >> > attributes
> > >> >> to allow extensions in namespaces other than those defined by the
> > >> >> markup specification may also define one or more specific
> > >> >> extension elements in
> > >> > the
> > >> >> namespaces that it defines. [Note: If the markup specification
> > >> >> includes a schema, any extension elements would normally be
> > >> >> constrained by the schema
> > >> > to
> > >> >> occur only in specific markup contexts. end note].
> > >> >>
> > >> >> If an MCE processor is configured to recognise extension elements,
> > >> >> it preserves them together with their attributes and contents.
> > >> >> See Clause 9
> > >> > for
> > >> >> details.
> > >> >>
> > >> >>
> > >> >> [Example:
> > >> >>
> > >> >>
> > >> > https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex
> > >> > ten
> > >> > sionEl
> > >> > em
> > >> >> ents/example1.xml
> > >> >>
> > >> >> In this example, the e1:foo element contains the unknown:foo
> element.
> > >> >> Suppose that a markup configuration contains an expanded name
> > >> >> ("http://www.example.com/e1", "foo") and that an application
> > >> >> configuration does not contain "http://www.example.com/unknown".
> > >> >> Then, the element e1:foo is an application-defined extension
> element.
> > >> >> Although the unknown:foo element does not belong to an understood
> > >> >> or
> > >> > ignorable
> > >> >> namespace, the MCE processor preserves it and does not report any
> > > errors.
> > >> > end
> > >> >> example]
> > >> >>
> > >> >> [Example:
> > >> >>
> > >> >>
> > >> > https://subversion.assembla.com/svn/IS29500/trunk/Part3/TestData/Ex
> > >> > ten
> > >> > sionEl
> > >> > em
> > >> >> ents/example2.xml
> > >> >>
> > >> >> In this example, Markup Compatibility elements and attributes
> > >> >> occur within
> > >> > the
> > >> >> extensionElement element, which is the only child of the root
> > >> >> element
> > >> > example.
> > >> >> Suppose that a markup configuration contains an expanded name
> > >> >> ("http://www.example.com/e1", "extensionElement").
> > >> >> Then, the MCE processor preserves the extensionElement element.
> > >> >> Therefore, MCE elements and attributes within it, namely
> > >> > mce:Ignorable="i1",
> > >> >> mce:ProcessContent="i1:bar1", mce:MustUnderstand="e1",
> > >> > mce:AlternateConent,
> > >> >> mce:Choice, and mce:Fallback, appear in the output document.  end
> > >> >> example]
> > >> >>
> > >> >> After receiving the output of an MCE processor, application
> > >> >> programs may further invoke an MCE processor to handle Markup
> > >> >> Compatibility elements
> > >> > and
> > >> >> attributes within extension elements.
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> Praying for the victims of the Japan Tohoku earthquake
> > >>
> > >> Makoto
> > >
> >
> >
> >
> > --
> >
> > Praying for the victims of the Japan Tohoku earthquake
> >
> > Makoto
>
>


-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20130823/ce8c5989/attachment.html>