MCE Revision Issue: §6, "Overview"

[Francis Cave]

I'm not so  keen on the phrase "blocks of additional features". A "block" is
something fairly concrete, whereas a "feature" is definitely an abstraction.
I would prefer "blocks representing additional features".

One way around the ignore/disregard problem would be to leave out both, e.g.
"Consumers might preserve extension elements even if they are unable to
handle them in any other way".

Francis




> -----Original Message-----
> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
> Sent: 14 August 2013 00:04
> To: 'SC 34 WG4'
> Subject: RE: MCE Revision Issue: §6, "Overview"
> 
> My late homework.  From the further discussion on the call, how about
this.
> This incorporates the points raised about preserving extensions and noting
> that before the words about disregarding them.  I also made a few
cleanups.
> 
> Existing:
> Application-defined extension elements specify a method for defining
> extensibility points within the markup specification. This allows
producers to
> introduce new features scoped to particular elements within the markup
> specification. Consumers can disregard these self-contained blocks of
> additional features.
> 
> Proposed:
> Application-defined extension elements specify a method for defining
> extensibility points within a markup specification. This allows producers
to
> introduce new self-contained blocks of additional features scoped to
> particular elements. Consumers might preserve extensions even if they are
> ignored and cannot be handled.
> 
> 
> I suspect there will be a question about "ignored" in the last sentence.
I
> tried using disregard to avoid using the term ignored since we have a
feature
> for ignorable namespaces, but that caused confusion.  I'd like to get
across
> that consumers can safely ignore extensions if they're not understood.  If
> someone can think of a better word, please suggest it.  I'm fine with
either
> ignored or disregarded since this is all an informative overview.
> 
> John
> 
> -----Original Message-----
> From: John Haug [mailto:johnhaug at exchange.microsoft.com]
> Sent: Tuesday, August 13, 2013 6:32 AM
> To: SC 34 WG4
> Subject: RE: MCE Revision Issue: §6, "Overview"
> 
> From the discussion on the call, how about this:
> 
> Application-defined extension elements specify a method for defining
> extensibility points within the markup specification. This allows
producers to
> introduce new features scoped to particular elements within the markup
> specification. Consumers can disregard these self-contained blocks of
> additional features and they might preserve extensions even if they cannot
> handle them.
> 
> 
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA
Makoto
> Sent: Tuesday, August 13, 2013 4:44 AM
> To: SC 34 WG4
> Subject: Re: MCE Revision Issue: §6, "Overview"
> 
> 2013/7/24 John Haug <johnhaug at exchange.microsoft.com>:
> > Good comment.  What I think I was getting at was that consumers that
> > don't understand the extension can safely ignore it.  The ext
> > definition in SpreadsheetML requires preserving unknown extensions
> > (18.2.7), the ones in PresentationML (19.2.1.11) and DrawingML
(20.1.2.2.14,
> 21.2.2.62) don't.
> 
> I think that this para should mention preserving rather than ignoring.
> Ignorable namespaces are never preserved, but app-defined ext elements can
be
> (but need not to be) preserved.
> 
> How about:
> 
> Aplication-defined extension elements specify a method for defining
> extensibility points within the markup specification.  Markup consumers
are
> expected to be ready to encounter any extensions at these points.  In
> particular, they might preserve extensions even if they cannot handle
them.
> 
> 
> Regards,
> 
> 
> 
> >
> >
> > Perhaps the best thing for Part 3 is to omit that last sentence.  That
> > paragraph is intended to give a rough informative overview of the
> > features in MCE, so saying anything about how they work (as opposed to
> > generally what they do) is probably not a good idea.
> >
> >
> >
> > John
> >
> >
> >
> > From: Francis Cave [mailto:francis at franciscave.com]
> > Sent: Monday, July 22, 2013 3:50 PM
> > To: 'SC 34 WG4'
> > Subject: RE: MCE Revision Issue: §6, "Overview"
> >
> >
> >
> > The edits to §6 Overview are mostly OK, I think, but I'm concerned
> > about the wording of the final bullet point. Here it is with the changes
> applied:
> >
> >
> >
> > "Application-defined extension elements specify a method for defining
> > extensibility points within the markup specification. This allows
> > markup producers to introduce new features scoped to particular
> > elements within the markup specification. Markup Consumers can
> > disregard these self-contained blocks of additional features."
> >
> >
> >
> > I think that the first two sentences are OK, but the final sentence
> > looks wrong to me. Markup Consumers MAY be able to disregard these
> > extension elements, but only if the markup specification permits a
> > Consumer to disregard them. The way that ext is specified in Part 1
> > means that it must be preserved if not understood, so they may never
> > be disregarded. See Part 1 §18.2.7.
> >
> >
> >
> > Francis
> >
> >
> >
> >
> >
> > From: Rex Jaeschke [mailto:rex at RexJaeschke.com]
> > Sent: 22 July 2013 18:46
> > To: SC 34 WG4
> > Subject: MCE Revision Issue: §6, "Overview"
> >
> >
> >
> > A few days ago, I posted to this email list, WG N 0264, "29500-3 (MCE)
> > Revision, WD0.91". It contains proposed changes by John H. based on an
> > action item he took at the Bellevue F2F meeting. This action item was:
> > Rework this so we don't appear to be introducing any new terms. Use
> > plain English.
> >
> >
> >
> > Please post your feedback to this list. If we get enough support,
> > we'll close this issue on the next teleconference; otherwise, we'll
> > deal with it at the Delft F2F meeting.
> >
> >
> >
> > Rex
> 
> 
> 
> --
> 
> Praying for the victims of the Japan Tohoku earthquake
> 
> Makoto