MCE blog post by Florian Reuter

[Jim Thatcher]

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