MCE blog post by Florian Reuter

Tue Oct 2 00:02:20 CEST 2012

Jim,

You did not miss any votes since there are no votes in
WG4.  But you did miss a discussion about impacts of
@ExtensionElements on existing applications of MCE
in the last teleconference.

The latest proposal (in the semantics wiki) is:

    Note: If Specification A references to the first edition
    of MCE, it might be a good idea to make a newer
    version of A reference to the second edition of MCE
    but prohibit the explicit use of @ExtensionElements.
    Then, existing programs for the current version of A
     continue to work for new data based on the newer
    version of A.

In the case of OOXML, this means that Parts 1 and 4
will disallow the use of @ExtensionElements, even when
Part3 allows it.   By doing so, existing OOXML applications
can handle new OOXML documents.  We had an extensive
discussion about this and John was happy.

>the existing lack of announcing application-defined extension elements,

Yes we agreed.

> we have agreed that it would be good to have such a mechanism,
> we have formally agreed to an overriding guideline for the "second edition" of MCE (and OPC) - that we do not break existing documents.

I declare consensus about the interaction of such a mechanism
and the guideline.  I do not think the first consensus is weaker
than the second.  Of course, every decision in WG4 can be revisited
later.

>It is my understanding that until we have reviewed a concrete proposal for an interoperable
>mechanism for announcing application-defined extension elements that is fully backward
>compatible, and voted to include that proposal in the revision of MCE, our current course
>is to address that need by explicitly specifying that this is "implementation-defined"
>requirement, and leave the details to the implementer. Did I miss that vote?

Until the 2nd edition of MCE is published, the first edition MCE
applies.  It provides
no mechanisms for specifying which element is application-defined
extension elements.
Implementations can do anything.  This unfortunately means that Part3 does not
provide interoperability of MCE.  However, in the context of Parts 1 and 4,
where app-defined ext elements are always extLst, this point is not relevant.

Regards,
Makoto

2012/10/2 Jim Thatcher <Jim.Thatcher at microsoft.com>:
> It's premature to state that "WG4 has agreed ... that the second edition must provide one such [as] (@ExtensionElement)." While it is true that our discussions have produces an apparent consensus regarding the existing lack of announcing application-defined extension elements, and we have agreed that it would be good to have such a mechanism, we have formally agreed to an overriding guideline for the "second edition" of MCE (and OPC) - that we do not break existing documents. It is my understanding that until we have reviewed a concrete proposal for an interoperable mechanism for announcing application-defined extension elements that is fully backward compatible, and voted to include that proposal in the revision of MCE, our current course is to address that need by explicitly specifying that this is "implementation-defined" requirement, and leave the details to the implementer. Did I miss that vote?
>
> Jim
>
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
> Sent: Friday, September 28, 2012 2:40 PM
> To: SC34
> Subject: Re: MCE blog post by Florian Reuter
>
> Florian is talking about the first edition MCE.  WG4 has agreed that it provides no interoperable mechanisms for announcing application-defined extension elements and that the second edition must provide one such (@ExtensionElement).  Florian probably did not want to say so in this blog post.
>
> Regards,
> Makoto
>
> 2012/9/27 Francis Cave <francis at franciscave.com>:
>> The question is: what can a configuration contain? So far the
>> semantics defined on the wiki page suggest that a configuration
>> contains a list of understood namespaces, but nothing else that I've
>> noticed. You're suggesting that a configuration can contain other
>> things, such as a list of application-defined extension elements,
>> inside which MCE processing is suspended. Following Florian's blog, to
>> this we could add a list of elements that cause MCE processing to be
>> resumed, when encountered within an application-defined extension
>> element. What other things could there be in a configuration? If any
>> conceivable extension of MCE could be in such a configuration, I think
>> we're in trouble. I'm hoping we can come up with a finite enumeration.
>>
>>
>>
>> Francis
>>
>>
>>
>>
>>
>>
>>
>> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
>> Sent: 26 September 2012 22:18
>> To: 'SC34'
>>
>>
>> Subject: RE: MCE blog post by Florian Reuter
>>
>>
>>
>> I think Murata-san's notion of a "configuration" as a required input
>> is a good way to think about this.  One can build an MCE preprocessor
>> from a full definition of functionality in Part 3.  Operating it
>> requires seeding it with some input parameters, which includes a set of understood namespaces.
>> This seems a non-issue to me, but am I not seeing something?
>>
>>
>>
>> John
>>
>>
>>
>> From: Francis Cave [mailto:francis at franciscave.com]
>> Sent: Tuesday, September 25, 2012 4:42 PM
>> To: 'SC34'
>> Subject: FW: MCE blog post by Florian Reuter
>>
>>
>>
>> Apologies, I managed to exclude the WG 4 mailing list from this bit of
>> the thread. Mea culpa!
>>
>>
>>
>> Francis
>>
>>
>>
>>
>>
>>
>>
>> From: Francis Cave [mailto:francis at franciscave.com]
>> Sent: 26 September 2012 00:15
>> To: 'John Haug'
>> Cc: 'Chris Rae'
>> Subject: RE: MCE blog post by Florian Reuter
>>
>>
>>
>> Hi John
>>
>>
>>
>> Yes, I suppose I was thinking about a generalized MCE processor, since
>> that is what I understand that Murata-san has been talking about.
>>
>>
>>
>> But I do understand what you're driving at. This means that an MCE
>> processor cannot be built solely be reading Part 3. The MCE
>> application may define additional features - such as those that
>> trigger suspension and resumption of MCE processing - which influence how the MCE processor is built.
>>
>>
>>
>> What worries me about that is that it means that MCE is only partially
>> defined by Part 3, and it seems to me that, if we accept that
>> unspecified features of MCE can be defined elsewhere, the value of
>> Part 3 is questionable, because it might be better just to define MCE
>> in its entirety for each application. Part 3 could perhaps be seen as
>> a reference model for constructing MCE applications, or at best
>> providing the definition of a minimum subset of the functionality of MCE applications.
>>
>>
>>
>> Can we do better than that? Can we restrict what features of an MCE
>> application are defined elsewhere? Or was it always the intention that
>> Part
>> 3 should only define MCE fundamentals and not the whole feature set?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Francis
>>
>>
>>
>>
>>
>>
>>
>> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
>> Sent: 25 September 2012 23:28
>> To: Francis Cave (francis at franciscave.com)
>> Cc: Chris Rae
>> Subject: RE: MCE blog post by Florian Reuter
>>
>>
>>
>> Hi Francis -
>>
>> I'm not sure about the foo:bar question.  I can think of one possible
>> case that might be useful but don't know what the intention of the authors was.
>> That will require a little investigating.  In general, of course,
>> removing anything is a tricky thing to be certain of, and may not be a great idea.
>>
>>
>>
>> As for the initialization question, Florian's may be one
>> implementation.  A simpler one might be simply to know which markup
>> languages the application supports and which of those support MCE.  In
>> that case, you can easily know where MCE should be enabled.  I think
>> all thinking about MCE processing has been in the context of an
>> application oriented around some markup language, which scopes the
>> problem well to that limited set of languages the application
>> understands.  Your question sounds more geared toward how a
>> generalized MCE preprocessor would need to work.  I don't think that
>> is as well defined right now.  My understanding is that a markup
>> specification defines within itself whether it supports MCE.  An
>> application understanding that markup spec should then know enough
>> about that markup spec to know whether MCE is valid within it.  There
>> may be no such thing as a generalized MCE preprocessor unrelated to an
>> application since the MCE processor needs a configuration as one of
>> its inputs.  Or, a degenerate MCE processor might be one with a null
>> configuration, where all namespaces other than MCE are not understood
>> - not overly useful. :)
>>
>>
>>
>> John
>>
>>
>>
>> From: Francis Cave [mailto:francis at franciscave.com]
>> Sent: Tuesday, September 25, 2012 1:15 PM
>> To: John Haug
>> Subject: RE: MCE blog post by Florian Reuter
>>
>>
>>
>> A very useful contribution.
>>
>>
>>
>> There's no mention in Florian's blog posting of anything resembling
>> <foo:bar/> in ACBs, as in Murata-san's example. Can we prohibit this?
>>
>>
>>
>> Florian's explanation of how specified elements can cause MCE
>> processing to be suspended or resumed is interesting and clear, but
>> seems to go well beyond what is specified in the standard, by my
>> reading. Florian suggests that the MCE processor can, as part of its
>> initialisation, be provided with a list of elements inside which MCE
>> processing is suspended and another list of elements inside which MCE
>> is resumed. Where does the MCE processor find such lists? There is
>> certainly no mechanism in the standard for specifying such lists, which means that implementations would not be interoperable.
>>
>>
>>
>> Francis
>>
>>
>>
>>
>>
>>
>>
>> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
>> Sent: 25 September 2012 19:54
>> To: e-SC34-WG4 at ecma-international.org
>> Subject: MCE blog post by Florian Reuter
>>
>>
>>
>> Trying again as this didn't seem to go through this weekend...
>>
>>
>>
>> FYI, Florian wrote a blog post summarizing MCE that is on the
>> OpenXMLDeveloper.org site.
>>
>>
>>
>> http://openxmldeveloper.org/blog/b/openxmldeveloper/archive/2012/09/21
>> /markup-compatibility-and-extensibility.aspx
>>
>>
>>
>> John
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>
>
>
>
>

-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto