MCE blog post by Florian Reuter

Francis Cave francis at franciscave.com
Thu Sep 27 12:23:11 CEST 2012


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/marku
p-compatibility-and-extensibility.aspx

 

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20120927/98723eb8/attachment.htm>


More information about the sc34wg4 mailing list