DR 13-0004 and extLst vs. ext
John Haug
johnhaug at exchange.microsoft.com
Wed Mar 13 01:37:28 CET 2013
We discussed DR 13-0004 on today's call and I summarized what I found from talking to someone on our team. I offered to share the info I obtained, so here it is, below.
John
From: Dan
To: John Haug
Subject: RE: extLst vs. ext
Both are in the application namespace as far as I know.
<a:blip r:embed="rId5" r:link="rId6">
<a:extLst>
<a:ext uri="{28A0092B-C50C-407E-A947-70E740481C1C}">
<a14:useLocalDpi val="0" xmlns:a14="http://schemas.microsoft.com/office/drawing/2010/main"/>
</a:ext>
</a:extLst>
</a:blip>
And I would have expected a MustUnderstand on an extLst and an ext to cause a parse error.
-dan
________________________________
From: John Haug
To: Dan
Subject: RE: extLst vs. ext
Sorry for the choppy mail access - I'm in Denmark at the moment.
Hm. The short version of what we're trying to do is: As part of the revision to MCE, they're introducing a flexible way to specify explicitly which elements are app-defined extension elements. In order to preserve backward-compat, we're going to list the Part 1 & Part 4 (Strict & Transitional - core Word/PPT/XL Open XML markup) extension elements (fully-qualified) as a hard-coded snapshot in time (e.g., http://schemas.openxmlformats.org/drawingml/2006/chart:ext). So, we need to make sure we have right whether it's extLst or ext! :)
Someone did a test with Office by adding a MustUnderstand="foo" to a trivial file created in Office that contained an extLst/ext. It was effectively ignored on the ext (file opened without complaint) but file open failed when it was on extLst. So, his conclusion was that ext is the extension element, as far as an MCE processor is concerned.
From: Dan
To: John Haug
Subject: RE: extLst vs. ext
My MCE processor has a notion of "turn off / pass through everything". Internally, it uses this when processing an untaken Choice. Similarly, when the application encounters an ext they don't understand, they invoke this mode so the ext is passed through as-is so they can round-trip it.
-dan
________________________________
From: John Haug
To: Dan
Subject: RE: extLst vs. ext
So does your MCE processor not have a notion of handling extension elements? By definition, extension elements are not part of the MCE namespace and are defined by the markup language that uses MCE.
From: Dan
To: John Haug
Subject: RE: extLst vs. ext
My preprocessor knows nothing about extList, it's just a passthrough same as <circle> or <text>.
extLst and ext are part of the application namespace, not the MCE namespace. The application processes the <extLst> and each <ext> to decide whether to understand them.
Now, that is an implementation detail. A preprocessor could accept a list of qualified names that are extList elements and a list of understood uris, and automatically filter them out like we do for ACBs.
-dan
________________________________
From: John Haug
To: Dan
Subject: RE: extLst vs. ext
Hah, I'll bet nobody would expect that! Hm, not sure what impact that will have. Does the preprocessor stop on extLst and hand that off to the app, or ext? That might be the distinction.
From: Dan
To: John Haug
Subject: RE: extLst vs. ext
I think both are application-defined extension elements, and the preprocessor doesn't know anything about them.
-dan
________________________________
From: John Haug
To: Dan
Subject: extLst vs. ext
Hi Dan -
I have a (hopefully) quick question while at another WG 4 meeting. From the perspective of the MCE preprocessor, which element is the application-defined extension element, extLst or ext? (You probably recall that extLst/ext are the extensions, most used by Excel, as I recall.) That is, does the MCE preprocessor hand off the contents of the extLst or the ext to the application to handle?
Thanks,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20130313/9bd58def/attachment-0001.htm>
More information about the sc34wg4
mailing list