Proposed text for Clause 9

[Francis Cave]

Murata-san

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,
"recognise" in this context means "preserve". 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.

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/Exten
> > 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/Exten
> > 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