RE: DR 10-0034 — MCE: Drop Application-Defined Extension Elements
Chris.Rae at microsoft.com
Sat Jun 11 02:50:56 CEST 2011
I think it would. We would just give it the core IS 29500 namespace, and the "extLst" element. Because this isn't used elsewhere in the standard, I think this would mean MCE could be easily disabled in the relevant areas without knowing the entire schema.
We'd also have to make a normative statement somewhere in the standard that "extLst" was an element name not to be used for any other purpose in future.
From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: 05 June 2011 19:12
To: e-SC34-WG4 at ecma-international.org
Subject: Re: DR 10-0034 — MCE: Drop Application-Defined Extension Elements
> Of course, this makes the implementation of MCE harder because an MCE parser has to know of the presence of ext elements. I think that could be made easier than forcing MCE implementers to also understand the schemas of Parts 1 and 4 - we could perhaps use "ext" as a generic extension element in MCE regardless of where it appears, or we could provide xpath type expressions to the various reserved elements. However we do it, though, I think this feature is something that we don't want to lose in IS 29500.
Thank you for your detailed analysis.
Now, the processing model (page 31) in Part 3 has a para as below:
The markup preprocessor transforms its input markup into
output markup that contains elements and attributes drawn
only from current and non-understood namespaces. This
transformation is disabled for input markup nested within an
application-defined extension element. The markup preprocessor
accomplishes its transformation using the following rules:
If we allow a collection of (namespaceUri, localName) pairs as an addtional input to the processing model, and the markup processor uses them for disabling the transformation, is your concern addressed?
More information about the sc34wg4