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

[Chris Rae]

Hello again - my apologies for taking so long to reply on this; it turns out to be more complicated than I'd thought. I think I now have a pretty good handle on how we (MS) used the MCE concepts.

I think the original intent of Part 3 was to allow vendors to extend using either subsumption of existing namespaces for extended content, or addition of new namespaces. However, it's certainly unclear in a few parts which concept the standard is talking about and there's a strange concept of "implicit subsumption" when talking about elements in ignorable namespaces.

Most of the situations in which Office extends existing markup involve the addition of new-namespaced attributes on existing elements. This is in accordance with the text of 11.2, "Namespace subsumption"..."Special considerations for attributes". That section states there that existing elements can be either extended using new namespaces (as we do) or existing ones, with implicit subsumption (which we do not do). The use of new namespaces for attributes also seems to be in line with 10.1.1, "Ignorable Attribute" but I'd agree that it certainly appears to contradict the statement in 9.1 that "Future versions of markup specifications shall specify new namespaces for any markup that is enhanced or modified by the new version".

If we agree that 11.2 allows attributes in new namespaces to be added to existing elements, I think Part 3 can be repaired by altering the wording of the statement in 9.1 to cover "...markup whose meaning is changed...". As long as the markup still made sense to an earlier consumer, then, the base namespace can remain the same. If we don't agree, I think we'll need to find a more clear way of determining which markup should be subsumed and which should not (does a new attribute on a <p> element mean a new <document>, for example?). 

During the course of investigating this, we came across a few places in which Part 3 is not very well-written. There is no prescriptive way given for a consumer to derive whether markup is subsumed, and there is vague wording in a few normative sections. There's an informative note in section 11.2 which mentions that " The statements above introduce a potential ambiguity " but proposes no solution; that should probably be turned into something more normative. I'm going to submit DRs for several of these, and hopefully we can improve this part as a whole.

Your thoughts,

Chris

-----Original Message-----
From: Chris Rae [mailto:Chris.Rae at microsoft.com] 
Sent: 23 June 2010 13:23
To: Alex Brown; e-SC34-WG4 at ecma-international.org
Cc: Jesper Lund Stocholm <jesper.stocholm at ciber.dk> (jesper.stocholm at ciber.dk)
Subject: RE: Proposed fix for DR 10-0016 ("MCE: Core Concepts")

Hi all -just wanted to say I'm digging up the right people on the dev teams just now; I'll report back on this thread.

Chris

-----Original Message-----
From: Alex Brown [mailto:alexb at griffinbrown.co.uk]
Sent: 23 June 2010 02:38
To: Chris Rae; e-SC34-WG4 at ecma-international.org
Cc: Jesper Lund Stocholm <jesper.stocholm at ciber.dk> (jesper.stocholm at ciber.dk)
Subject: RE: Proposed fix for DR 10-0016 ("MCE: Core Concepts")

Chris hi

> Howdy... sorry, I do see what you mean about "enhanced or modified"
> implying that subsumption is required.
> 
> When we planned our extensions, we did think we were being compliant 
> with part 3 - I believe we went with adding children in other 
> namespaces over subsumption because subsumption makes for a worse 
> back-compat story (older application lose the entire elements, rather 
> than just the extra attributes).

But surely any legacy apps which handled MCE at all would have to handle subsumption, since that is part of MCE?

>I think we were under the impression that either subsumption or  the 
>use of ignorable namespaces for children were valid.

Wouldn't that depend on interpreting "modified or enhanced" as meaning nothing? But once you start adding novel new features to an existing vocabulary I don't see any way of claiming you are doing anything other than modifying or enhancing that markup!

Perhaps the text could be amended in line with your approach ... but that still leaves two different approaches with (it seems to me) no standards-based way to decide between them -- which is not good for interoperability.
 
> I'm going to go and find the developers to see how they were reading 
> the standard - would it be ok if I reported back on the next WG4 call 
> and we can work out where to go from there?

Well that is over two weeks away. I was rather hoping we could move towards a resolution soon with the benefit of some on-list discussion -- things are rather becalmed at the moment. 

That said I won't be able to attend the next conference calls, so I'll leave it to others to comment ...

- Alex.

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