Proposed text for Clause 9
John Haug
johnhaug at exchange.microsoft.com
Wed Sep 11 18:02:02 CEST 2013
Tonight's homework: Based on today's discussion, I propose to change the one normative sentence below (immediately under "==Text of Clause 9==") to the following; the rest of the proposed text remains the same.
An application-defined extension element is a designated element in a markup specification, the contents of which are not processed by an MCE processor. The semantic impact of application-defined extension elements on MCE processing is covered in §9.
[remaining informative statements follow]
From: John Haug [mailto:johnhaug at exchange.microsoft.com]
Sent: Tuesday, September 10, 2013 1:34 PM
To: 'SC 34 WG4'
Subject: RE: Proposed text for Clause 9
>From today's discussion of this, I propose the following text. I'm not yet convinced this is ideal, but it's a target for further discussion. This also intends to capture Francis' comments below and in the meeting about not necessarily constraining MCE processors to ignore and preserve app-defined extension elements the way the current text does. Implications of the simple, generalized definition of an app-defined extension element include: potential changes to clause 10 steps about extension elements if we want to enable behavior other than the current pass-through, or we could make pass-through the default that can be overridden by a markup specification.
(Background for those not at the meeting: As Rex walked through the comments on the draft 0.92 document, Murata-san indicated he didn't like the revised text he had proposed. I agreed to take a look at revised clause 9 text, with a goal of focusing on the syntactic and defining what an application-defined extension element is, but not getting into related behavior, since that's covered in clause 10 semantic definitions. I leveraged some of Murata-san's proposed text because it had improvements.)
==Text of Clause 9==
An application-defined extension element is an element occurring in the markup configuration for which the MCE processor's processing behavior is defined by the markup specification.
[Rationale: This mechanism is intended, but not limited, to be used by markup specifications to create extensibility points within the markup specification. end rationale]
[Note: If the markup specification includes a schema, an extension element might be constrained by the schema to occur only in specific markup contexts. end note]
[Note: The content of an application-defined extension element might contain markup that uses Markup Compatibility constructs. A consuming application might invoke an MCE processor to process the content of application-defined extension elements contained in an output document constructed by an MCE processor. end note]
[Example:
<example
xmlns:e1="http://www.example.com/e1"
xmlns:unknown="http://www.example.com/unknown">
<e1:foo>
<unknown:foo/>
</e1:foo>
</example>
In this example, the e1:foo element contains the unknown:foo element. Suppose that an MCE processor's markup specification contains the expanded name ("http://www.example.com/e1", "foo") and its 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, according to the semantic definitions in §10, the MCE processor does not report the existence of that elements as an error. end example]
==Move this example to Annex A==
[Example:
<example
xmlns:mce="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:i1="http://www.example.com/i1"
xmlns:e1="http://www.example.com/e1">
<extensionElement>
<foo1
mce:Ignorable="i1"
mce:ProcessContent="i1:bar1"
mce:MustUnderstand="e1">
</foo1>
<mce:AlternateContent mce:Ignorable="i1" >
<mce:Choice Requires="e1" > ... </mce:Choice>
<mce:Fallback i1:foo=""> ... </mce:Fallback>
</mce:AlternateContent>
</extensionElement>
</example>
In this example, MCE elements and attributes occur within the extensionElement element, which is the only child of the root element example. Suppose that an MCE processor is configured to preserve extension elements of 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]
==Related edits==
Possible changes to extension element discussion in clause 10 (steps subclauses).
Part 1 contains "markup consumer" and "markup producer" (18.2.10) and we may want to edit that away. (Related to the previous change recommended by Murata-san to move away from those terms, below.)
Should the definitions in 10.1 for markup configuration and application configuration be pushed into the Terms and Definitions definitions of those terms to make them more explicit?
John
From: Francis Cave [mailto:francis at franciscave.com]
Sent: Thursday, August 22, 2013 8:46 AM
To: 'SC 34/WG 4 mailing list'
Subject: RE: Proposed text for Clause 9
Sorry, Murata-san, I should have read the current working draft more carefully.
So, the behaviour of MCE processors with respect to extension elements is currently defined as part of the processing model in Clause 9. If we accept that ALL applications of MCE must handle extension elements as currently specified in Clause 9, this is the right place to specify such normative behaviour. If, on the other hand, we can agree that SOME applications of MCE (not OOXML) might wish to specify different behaviours for MCE processors with respect to extension elements, we either have to remove such normative requirements from Clause 9, or make it clear that they are not mandatory but are recommended as likely best practice, or weaken them further by including them purely as examples of how MCE processors might behave.
As I have already stated, my main concern is that, if we are revising Part 3 so that MCE can be applied in markup specifications other than OOXML, we should think carefully about which behaviours need to be normative for all MCE processors, regardless of MCE application, and which should be specified by the application. Clearly it makes sense to specify normatively all behaviours with respect to MCE constructs, i.e. constructs that are represented by elements and attributes with names in the MCE namespace. But I don't think this necessarily applies to extension elements - which are, after all, supposed to be "application-defined". I think it can be argued that if they are application-defined, the way they should be handled by MCE processors should also be application-defined. Otherwise, why not define an element in the MCE namespace called 'mce:extension-element' (or 'mce:ext', if you prefer) and leave it at that? I know that OOXML hasn't done that, and maybe we feel that it should have done, but it didn't, and therefore the question has arisen - in my mind, at least.
Kind regards,
Francis
From: eb2mmrt at gmail.com<mailto:eb2mmrt at gmail.com> [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: 22 August 2013 16:19
To: Francis Cave
Cc: SC 34/WG 4 mailing list
Subject: Re: Proposed text for Clause 9
2013/8/13 Francis Cave <francis at franciscave.com<mailto: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> [mailto: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> [mailto: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> [mailto: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/20130911/5daa0357/attachment-0001.html>
More information about the sc34wg4
mailing list