DR 13-0004 and extLst vs. ext

[MURATA Makoto]

My apologies.  Your interpretation does succeed in
explaining why errors are raised for extLst.  You can
even argue that yours is consistent with the original
wording in the 1st Edition Ecma OOXML, which
uses the word "contents".

But I have a question.  If MCE processing handles
attributes of application-defined extension elements,
will MCE ignore some attributes (when they are
ignorable)?

Regards,
Makoto

2013/5/15 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
> 2013/5/15 John Haug <johnhaug at exchange.microsoft.com>:
>> But since extLst is the extension element and not ext, Office doesn't look at ext because it's inside the extension element.  So, no error raised for ext.
>
> Both your interpretation and my interpretation can
> explain why no errors are raised for ext.
>
> But yours fail to explain why errors are raised for
> extLst.
>
> Regards,
> Makoto
>
>> Right?
>>
>> -----Original Message-----
>> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
>> Sent: Tuesday, May 14, 2013 5:08 AM
>> To: SC 34 WG4
>> Subject: Re: DR 13-0004 and extLst vs. ext
>>
>> 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
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto