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

Alex Brown alexb at griffinbrown.co.uk
Thu Jul 1 08:38:17 CEST 2010


Chris hi

Thanks for this ...

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

I think we should steer clear of any normative provisions which rely on the "meaning" of markup, or of markup "making sense" - however formally we try to re-word this, it will remain untestable. I think the only formal provisions we can usefully make about markup relate to syntax (including testing validity), which can be decidably tested.

> 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?).

Okay, I think it's clear then that subsumption is not a well-described feature, or a required one (or even perhaps an understood one). So why not remove it entirely? 

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

Removing subsumption has the advantage of allowing us to erase a lot of  this cruft and will result in a smaller text.

The way I see it, alternative content is markup for which "all bets are off" anyway (except that the MCE Namespace is not used in content). I  think subsumption is conceptually and technically problematic, and doesn't actually help implementers if (on top of that) it is optional anyway.  

Or do any experts think "subsumption" is useful concept?

In general I agree that Part 3 is poorly drafted. I know a revision of Part 2 is being proposed -- perhaps we should grasp the nettle and revise Part 3 now also?

- Alex.

______________________________________________________________________
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