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

[Chris Rae]

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.

Chris

-----Original Message-----
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.



Chris,

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?

Cheers,
Makoto