SUSPECT: DR-13-0009, "Parts 1 & 4 Edits Relating to the Part 3 Revision"

[Francis Cave]

Hi John

> Great material.  A few comments/questions.
> 
> 1.
> Part 1 clause 10 new text: "the Application-Defined Extension Elements
extLst
> and ext specified by this Part"
> 
> We have that DR about extLst vs. ext that hasn't been closed yet.
Dependent on
> that.  Not getting off into that discussion here. :)

Agreed!

> 2.
> Part 1 clause 10 new text: "An MCE processor shall be configured so as not
to
> process the content of any extension element specified by this Part of
ISO/IEC
> 29500, i.e., specifically not to process any instance of an element or
> attribute in the MCE namespace for which an extension element is an
ancestor
> element."
> 
> Isn't the requirement that an MCE processor suspend processing within an
> extension element something defined in Part 3 and ought not be within Part
1?
> Does adding that sentence add potential confusion about the question we've
> previously resolved around a consuming application choosing to send
understood
> extensions back into an MCE processor?  I'd suggest omitting it, but I
want to
> better understand why it was added.

This depends upon the outcome of the on-going discussion about where the
behaviour of MCE processors with respect to extension elements should be
specified. See separate email thread(s) about that.

> 3.
> Part 1 clause 18.2.7 new text: "that is discarded as a result of either
MCE
> processing (when consuming)"
> 
> Is there a typo?  As a result of either MCE processing or what?

Good catch. I think that deleting the word "either" makes it say what was
intended. Actually, I think that "(when consuming)" is probably redundant,
since the whole paragraph is about what happens when extension lists are
processed by consumers.

> 4.
> Part 1 clause 18.2.7 suggested replacement for the highlighted example:
> "[Example: If a spreadsheetML sheet contains several extensions within an
> extension list and the sheet no longer exists when producing the resulting
> markup document, the extensions associated with that sheet are not written
> out. end example]"

Yes, that's better, but maybe could be improved as follows:

"[Example: If, when consumed by a SpreadsheetML editor, a sheet contains
several extensions within an extension list, but the sheet no longer exists
after editing, the extensions associated with that sheet are not written out
in the resulting edited SpreadsheetML document. end example]"

> 5.
> Part 1 clause 18.2.10 highlighted text: "describe how markup producers and
> consumers must generate and consume markup documents containing
application
> defined extension elements, including how to avoid and when to generate
error
> conditions."
> 
> Perhaps, "..., including how to handle unexpected conditions."  Perhaps
that
> clause in the sentence can be removed.

Yes, it is probably best to remove this clause, as it unnecessarily
summarises some of what is said in the referenced Clauses.

> 6a.
> Part 1 clause L.7.3.4.2: "This doesn't seem to offer anything over and
above
> what Part 3 has."
> 
> That raises the spectre of questioning the existence of other parts of the
> Primer.

Maybe, but the risk is that what is said in the Primer doesn't say quite the
same thing as Part 3 and this could confuse implementers. I know that
there's an argument for there being a single Primer where implementers can
find everything, rather than having to jump back and forth between different
Clauses, Annexes and Parts. If we keep this kind of material in Part 1
§L.7.3, we have to accept that every time we do maintenance on Part 3, we
have to check that what it says in §L.7.3 is consistent with whatever
revisions are made to Part 3.

> 6b.
> "In any event. ISO editing rules do not permit a parent [sub]clause to
contain
> text if it has subclauses."
> 
> This is a problem elsewhere in the Primer.  Should we scour it for this
issue
> or just leave it be?  We're not doing a revision to Part 1 so can't we
ignore
> those rules?

I'll leave this one to Rex!

> 6c.
> There are further comments about duplicated info.  Is there a hint that we
> ought to consider the entirety of L.7.3 Future Extensibility (pages 5001-
> 5009)?

See my response to 6a.

Kind regards,

Francis



> John
> 
> -----Original Message-----
> From: Rex Jaeschke [mailto:rex at RexJaeschke.com]
> Sent: Friday, August 16, 2013 9:22 AM
> To: SC 34 WG4
> Subject: SUSPECT: DR-13-0009, "Parts 1 & 4 Edits Relating to the Part 3
> Revision"
> 
> When this DR was first submitted, it addressed only a small fraction of
the
> larger problem. Eventually, Francis and I decided to broaden the scope of
the
> DR to address the general problem. As such, we've given the DR a new
title,
> rewritten the DR problem statement, and written a paper, N0266, to help
> resolve this DR.
> 
> Rex