Proposed text for Clause 9

[Francis Cave]

Murata-san

A couple of comments:

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
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.

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?

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/ExtensionEl
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/ExtensionEl
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.