FW: MCE blog post by Florian Reuter

[Francis Cave]

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/20120926/d95bef95/attachment-0001.htm>