DR 13-0004 and extLst vs. ext

[MURATA Makoto]

No, your interpretation does not explain why my experiment
caused a failure for @MustUnderstand at extLst but not on ext.

Suppose ext is an app-defined ext element.  In your interpretation,
its @MustUnderstand is examined and an error should be raised.
But it is not raised.

Regards,
Makoto

2013/4/10 John Haug <johnhaug at exchange.microsoft.com>:
> Not sure how far into talking about this Murata-san was dropped from the
> call.  What I was saying, in short: A preprocessor could process MCE
> attributes on an extension element and ignore the contents of the extension
> element, or it could ignore MCE attributes on the extension element itself.
> It seems reasonable to me (I’ll check the intent with the MCE people here)
> that if the preprocessor is looking at an extension element it probably
> processes the MCE attributes on it, but ignores the contents.  That would
> explain why Murata-san’s MustUnderstand experiment caused a failure when it
> was on extLst but not on ext.
>
>
>
> I think the most relevant thing is Part 1, section 10.1.2 which refers to
> extLst, not ext.
>
>
>
> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
> Sent: Tuesday, March 12, 2013 5:37 PM
> To: 'SC 34 WG4'
> Subject: DR 13-0004 and extLst vs. ext
>
>
>
> 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! J
>
>
>
> 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



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto