MCE blog post by Florian Reuter

[MURATA Makoto]

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