Proposed fix for DR 10-0016 ("MCE: Core Concepts")

Alex Brown alexb at griffinbrown.co.uk
Tue Jun 22 10:11:27 CEST 2010


Chris hi

I don't understand your comment #2 -- in particular what is meant by "this can only be done".

To limit the discussion to OOXML (MCE drafting is more complex because it targets general extensibility), as I have written the text, the only way that OOXML Namespaced markup can be used in MCE content is if elements/attributes are *removed* relative to the original permitted markup -- if added, then the markup is "enhanced or modified" and users must use subsumption.

Maybe even this is too lax.

Taking a step back, my thinking here is this.

1.MCE provides a mechanism of mixing foreign markup into standard content

2. Sometimes, it is desired to mix in foreign markup which is a tweaked version of the original

3. In this case, the question arises: can we re-use the original standard's Namespace, or shall we subsume the vocabulary into a new Namespace we invent?

4. According to IS 29500 as published, we must subsume if the markup is "enhanced or modified". Yet this is too vague to be decidable.

5. I am attempting to introduce a *more formal* definition of "enhanced or modified" to rectify this.

6. As I have written it, the test is that if new stuff is added to the standard markup, then it must be subsumed. If the new markup is feasibly valid then it's okay to re-use the old Namespace.

Generally, MCE is a mess and need to be redrafted (and maybe redesigned). This is evidenced by the apparent situation we have now, in which MS have managed to mis-apply it to all their Office 2010 extensions, rendering them non-conformant. If the inventors don't understand it, what chance the rest of us?

This proposal is a sticking plaster to try and make this Part somewhat intelligible in the short term.

I suppose another option here would be (yet again) to align the Standard to what MS has done. This could be done by ripping out all mentions of subsumption throughout the Standard (since, as MS have done it, there appears to be no scenario in which subsumption is required). 

- Alex.



> -----Original Message-----
> From: Chris Rae [mailto:Chris.Rae at microsoft.com]
> Sent: 21 June 2010 20:53
> To: Alex Brown; e-SC34-WG4 at ecma-international.org
> Subject: RE: Proposed fix for DR 10-0016 ("MCE: Core Concepts")
> 
> Hi Alex - thanks for taking a look at this. I agree with the two-step 
> process but I have made a couple of comments in the doc and reattached it.
> 
> Chris
> 
> -----Original Message-----
> From: Alex Brown [mailto:alexb at griffinbrown.co.uk]
> Sent: 21 June 2010 07:27
> To: e-SC34-WG4 at ecma-international.org
> Subject: Proposed fix for DR 10-0016 ("MCE: Core Concepts")
> 
> Dear all,
> 
> I think this DR can be resolved in two steps.
> 
> The first step is to introduce a definition for the term "feasibly 
> valid" as
> follows:
> 
> ----begin
> 
> feasibly valid
> 
> an XML document or well-balanced fragment is feasibly valid if it can 
> be transformed into a valid document by inserting any number of 
> attributes and elements anywhere in the tree.
> 
> ----end
> 
> Section 9.2 of Part 3 can then be amended as in the attached document...
> 
> Thoughts?
> 
> - Alex.
> 
> --
> Alex Brown
> Convenor, ISO/IEC JTC 1/SC 34/WG 1
> Editor, ISO/IEC 19757-1 (DSDL Overview) Editor, ISO/IEC 19757-5 
> (Extensible Datatypes)
> 
> 
> 
> __________________________________________________________
> ____________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> __________________________________________________________
> ____________
> 
> __________________________________________________________
> ____________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> __________________________________________________________
> ____________

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________


More information about the sc34wg4 mailing list