MCE discussion points

[MURATA Makoto]

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