Proposed text for Clause 9

MURATA Makoto eb2m-mrt at asahi-net.or.jp
Tue Aug 13 14:10:34 CEST 2013


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



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto


More information about the sc34wg4 mailing list