DR 10-0034 — MCE: Drop Application-Defined Extension Elements
Chris Rae
Chris.Rae at microsoft.com
Wed Jun 1 22:31:00 CEST 2011
http://cid-c8ba0861dc5e4adc.office.live.com/view.aspx/Public%20Documents/2010/DR-10-0034.docx
This DR proposes the removal of Application-defined Extension Elements from Part 3, as extLsts and MCE belong to different layers and should not be discussed in tandem.
I've been researching this DR for some time, and unfortunately my position is that we shouldn't do this, although I certainly do see the logic of it. The key change that would be made by effecting this DR would be to allow MCE processing to be performed inside extLsts. The core problem I have with this is that extLsts are intended for future expansion, and their content is to be retained by applications and then written back into the file when it is saved. If the earlier-version consuming application were to parse MCE content inside that extLst, it will be parsing it for itself, and not for the future application. Let's say I build an Office application, Chris Office 2011, which allows sound effects to be applied to conditional formatting. I decide to store this data inside extLsts because I'd like other Office applications to round-trip that data. So my conditional formatting in the file looks like:
<conditionalFormattingElements>
<extLst>
<ext uri="myurl" xmlns:co11="http://chrisoffice/2011">
<co11:soundeffect>
<co11:sourceFile>moo.mp3</co11:sourceFile>
</co11:soundeffect>
</ext>
</extLst>
</ conditionalFormattingElements>
Now we add the ability to use video as well as MP3 in ChrisOffice 2013. We want to allow ChrisOffice 2011 to understand everything except the video (without duplication) so we make the video segment ignorable, and write out:
<conditionalFormattingElements>
<extLst>
<ext uri="myurl" xmlns:co11="http://chrisoffice/2011">
<co11:soundeffect mc:Ignorable="co13" xmlns:co13="http://chrisoffice/2013">
<co11:sourceFile>moo.mp3</co11:sourceFile>
<co13:sourceVideo>cow.mpg</co13:sourceFile>
</co11:soundeffect>
</ext>
</extLst>
</conditionalFormattingElements>
ChrisOffice 2011 will discard the video segment when it reads the file, which is our desired behaviour. However, because the co13 namespace is marked as ignorable, other applications will also discard the video segment even though they are unable to process any of the rest of the content inside the extLst. This is neither desirable nor necessary for an implementation - we should be able to round-trip the content of extLsts that we don't understand, as otherwise we've significantly decreased the worth of that extension feature.
Of course, this makes the implementation of MCE harder because an MCE parser has to know of the presence of ext elements. I think that could be made easier than forcing MCE implementers to also understand the schemas of Parts 1 and 4 - we could perhaps use "ext" as a generic extension element in MCE regardless of where it appears, or we could provide xpath type expressions to the various reserved elements. However we do it, though, I think this feature is something that we don't want to lose in IS 29500.
This might be a good topic for discussion in Berlin.
Chris
More information about the sc34wg4
mailing list