MCE discussion points

[MURATA Makoto]

> Murata-san asked:
> The above (correct) para is about ProcessContents, but  John's question is about resumption of MCE processing within application-defined extension elements.  These two are completely different beasts.
>
>
> There is no indicator or trigger that says "hey, re-establish MCE processing".  It's implicit - e.g., that the markup handed off by the preprocessor to the host application, containing an un-preprocessed extension element, could be sent back to a preprocessor by the host application if it chose to do so / knew it ought to (because it knows the host schema that's using MCE - that is, it has more contextual knowledge about the markup/schema than the simple MCE preprocessor does).

Understood.  This is consistent with what Chris and John have said.

>
> ----------
> Murata-san asked:
> How can the MCE processor know why the content of XMLDataSource of XAML should not be affected by markup compatibility rules?   Simply impossible as of now.
>
>
> In discussing with the MCE folks, I got stuck on his use of it being explicit in "schema" meaning a XSD/RNG/etc. file.  What he's saying is that the markup specification incorporating MCE defines in some way which elements are extension elements.  In our terms, it's part of the preprocessor's "configuration".

OK.

> He says: "The original intent was that the namespace specifications would state which elements in them should be treated as extension in MCE, not the other way around.

This is one possible approach.  But all other behaviors of MCE processors are
triggered by what is explicitly specified in the given document.   I prefer some
explicit mechanism for declaring app-defined ext elements.

Regards,
Makoto

>
> ----------
> There are also a few specific comments that I missed in their review of the Wiki text.  I paraphrase them below:
>
> 1. The references to the ext elements should be extLst.

I still think that this is mistaken.  Attached please find two
excel documents containing @MustUndrestand.  One specifes
this attribute at an extLst element while the other specifes
it at an ext element.  The former raises an error, while
the latter does not.


>
> 2. For the AlternateContent and Choice elements, the xmlns attribute is also allowed.  ("An AlternateContent element shall not have unqualified attributes, but may have qualified attributes." ... "A Choice element may have qualified attributes.")

"xmlns" is not an attribute, I believe.  It is a namespace declaration.

>
> 3. Re: the editorial note under AlternateContent ([Editorial note: Are child elements of ignorable and understood namespace names allowed (in other words, should we consider configurations)?   Or, should we allow namespaces for future versions of MCE only, and disallow configurations to contain such namespaces?]) Office allows Ignorable content under AC, such as
>      <mc:AlternateContent>
>           <no:no mc:Ignorable="no" />
>           <mc:Choice Requires="o"/>
>      </mc:AlternateContent>

What happens when the namespace for the prefix "no" is *understood*?
MCE syntax error?  Or, no errors?

>
> 4. Re: the Choice element ("Parent elements of Choice elements shall be AlternateContent elements."), the parent of a Choice can also be an Ignorable/ProcessContent element.  For example:
>      <mc:AlternateContent>
>           <no:no mc:Ignorable="no" mc:ProcessContent="no:no">
>                <mc:Choice Requires="o">
>                     <yes:yes />
>                </mc:Choice>
>           </no:no>
>      </mc:AlternateContent>

I am surprised.  This can't be true.  The first Ecma OOXML already had a
para as below:

    An AlternateContent element shall contain one or more Choice child
elements,
    optionally followed by a Fallback child element.

> 5. Re: the crossed-out sentence 2.a. under Step 3: Combination of ignoring and selecting ("a. Each MustUnderstand attribute at such an element shall be examined as specified in Step 4 before it is unwrapped.") - This is what Office does. As each Choice is examined, a MustUnderstand on it is processed. However, there is little reason for someone to write XML this way.

Makes sense!

Regards,
Makoto
>
>
>
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
> Sent: Thursday, April 4, 2013 6:14 PM
> To: SC 34 WG4
> Subject: Re: MCE discussion points
>
> John,
>
> Thanks for this note.  Let me ask some questions to the original authors.
>
>
>> ===== COMMENT 1: Suspension and resumption of MCE processing =====
>>
>> John asked:
>>
>> Section 12 of IS 29500 Part 3 (MCE) indicates that, even though MCE
>> processing is normally suspended within application-defined extension
>> elements, a markup specification may resume MCE processing within
>> extension element.  However, no indication is given how this is to be
>> specified. "A specification for an element nested somewhere within..."
>> As part of the ongoing revision of MCE, it has been proposed to either
>> make this explicit via new MCE markup or to remove this "feature".
>> Are you aware of any implementations of MCE that actually use this?
>>
>>
>>
>> Reply:
>>
>> Both of the features referenced were used in XAML.
>>
>>
>>
>> The quoted part of the specification appears to be intended to capture
>> the behavior of the XAML parser processing content of an
>> XmlDataSource. A XAML document author can supply the XML data inline
>> in a XAML document using an XmlDataSource element. The XML is taken
>> literally with no markup compatibility rules applied.
>>
>>
>>
>> This feature allows literal quoting of XML that might or might not
>> contain its own markup-compatibility attributes. It prevents
>> declarations that were intended to apply to the container from applying to nested XML content.
>>
>> ProcessContent was intended to allow markup-compatibility documents to
>> simulate HTML's default processing of unknown elements.  The
>> motivating example was,
>>
>>     <p>This is some <v2:emphasis>important</v2:emphasis> text</p>
>>
>> where v2:emphasis was an element introduced in version 2 that would
>> display the text as emphasized in some version 2 specific way but the
>> author was OK with the text appearing normal in v1. ProcessContent
>> allows emphasis to be ignored without losing the word "important".
>
> The above (correct) para is about ProcessContents, but  John's question is about resumption of MCE processing within application-defined extension elements.  These two are completely different beasts.
>
>>
>> ===== COMMENT 2: ExtensionElements =====
>>
>> John note: We had a lengthy discussion about the utility of specifying
>> what is an extension element.  After a bit of back-and-forth, I tend
>> to agree with the argument that it's not necessary to know which
>> elements are extension elements.  In short, the MCE preprocessor
>> doesn't care that something is an extension element, it just cares
>> whether the namespace of a given element is understood by whatever get
>> the processed markup.  That next module may know and care that an
>> element is an extension so it knows how to parse it, but that's out of scope for the MCE preprocessor.
>>
>>
>>
>> Comment:
>>
>> Let me try to explain my confusion. I think it can best be explained
>> by the concepts below of the processed and raw info-sets. MCE can be
>> thought of as a processing algorithm to turn raw info-sets into
>> processed info-sets. If the processing is successful, the processed
>> info-set would only contain elements and attributes declared as
>> understood to the MCE processor. That is, all non-understood elements
>> and attributes are either removed (if they are ignorable),
>> re-namespaced (for subsumed namespaces) or cause the processing to fail (MustUnderstand).
>>
>>
>>
>> Given this, I don't see where ExtensionElements fits. Either an
>> element or attribute is understood or it is not. I am not sure how to
>> think about an element that is some middle ground. If a consumer of
>> the processed info-set can make sense of the element (e.g., it is
>> valid in its schema), then the namespace is understood. Understood,
>> from an MCE perspective, is just whether or not the namespace should
>> be part of the processed info-set, not that it is fully understood by the consumer of the processed info-set.
>> Either the namespace appears or it doesn't, I don't see a middle
>> ground. In this light, extensions are just understood content, unless
>> I am missing something important.
>
> XmlDataSource may contain any element including those in non-understood namespaces.  Such an element appears in the output.
>
> How can the MCE processor know why the content of XMLDataSource of XAML should not be affected by markup
> compatibility rules?   Simply impossible as of now.
>
> Regards,
>
> Makoto



--

Praying for the victims of the Japan Tohoku earthquake

Makoto