RE: DR 10-0034 — MCE: Drop Application-Defined Extension Elements

Chris Rae Chris.Rae at
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.


-----Original Message-----
From: eb2mmrt at [mailto:eb2mmrt at] On Behalf Of MURATA Makoto
Sent: 05 June 2011 19:12
To: e-SC34-WG4 at
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 mailing list