Proposed text for Clause 9

John Haug johnhaug at exchange.microsoft.com
Thu Aug 15 22:34:14 CEST 2013 

May I risk wading into this?  I think I understand Murata-san's points and I think the general direction of his text is OK.  But I also think Francis has a point about the way the language is used.

Re: the second paragraph:
I believe it ought not mention preservation, since that is an optional function of the markup consumer.  Murata-san pointed out that "MCE processors simply pass application defined extension elements to application programs" which is correct.  But I agree with Francis that the language of the second paragraph sounds like "extension elements shall be preserved in the output document".  May I suggest that the second paragraph be reformed to simply point to section 10 for rules about how MCE processors handle extension elements?

Re: Murata-san's follow-up comment:
	> "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 that means the point of the second paragraph is to state the markup configuration remains unchanged (not sure if that is the point), then I'd suggest it's not necessary to state that since there is no indication in the text that the markup configuration would ever change.

Re: the last paragraph:
I suggest we make that a Note.  It's good clarifying information worth making clear that we consider it normal behavior.  Even though the whole clause 9 is informative, the statement is about something outside the scope of specifying an MCE processor and I think it would make the intent that it's ancillary information more clear by making it an explicit Note.

The only thing I can't evaluate is Francis' statement " Your proposed text ... defines an extension element somewhat more narrowly than I had proposed in my draft text".  I don't know what original draft text is referred to here.  It looks like Murata-san's text (and the relevant bits of clause 10) mirrors what is specified in the existing Part 3.

John


-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com] 
Sent: Tuesday, August 13, 2013 5:56 AM
To: 'SC 34/WG 4 mailing list'
Subject: RE: Proposed text for Clause 9

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.

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.

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

More information about the sc34wg4 mailing list