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

[John Haug]

Re: discussion about this DR here in Delft

One additional thing related to this was found by one of our support people.  The last sentence in the third paragraph of the Part 4 Introduction refers to a clause in Part 1 that was removed as a result of DR 09-0316/0317/0318.  I propose we simply remove that sentence:
"Part 1, §2.4, "Document Conformance", notes that WML Strict, SML Strict and PML Strict documents do not use any of the features defined in Part 4. "

-----Original Message-----
From: Francis Cave [mailto:francis at franciscave.com] 
Sent: Friday, August 23, 2013 7:06 AM
To: 'SC 34 WG4'
Subject: RE: SUSPECT: DR-13-0009, "Parts 1 & 4 Edits Relating to the Part 3 Revision"

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