DR-14-0014 - A Proposed Resolution

[Francis Cave]

The issue appears to boil down to the fact that there is no standardized definition of what it means to merge a range of cells. The nearest that the standard comes to doing this is in L.2.2.13, i.e. in the Primer, where it says:

"L.2.2.13 Merged Cells

<mergeCells>
	<mergeCell ref="D13:H14"/>
</mergeCells>

In the example, cells D13:H14 have been merged into a single, larger cell. Note that the cell table itself doesn't reflect this merge, but it does reflect the data content and formatting. Specifically, the top-left cell in a merged collection of cells contains the value, and all the cells reflect the various border formatting."

The last sentence sounds normative, although the Primer is non-normative. It contradicts what is said in the example (also non-normative) in 18.3.1.55:

"[Example:

This example shows that three ranges are merged. The formatting and content for the merged range is always stored in the top left cell.

<mergeCells>
	<mergeCell ref="C2:F2"/>
	<mergeCell ref="B19:C20"/>
	<mergeCell ref="E19:G19"/>
</mergeCells>

end example]"

The safest - but least helpful - approach would be to say in 18.3.1.55 that when a range of cells is merged, the content and formatting of the merged range are combined, but the process by which they are combined is unspecified / implementation-dependent. My fear is that to try to specify anything more interoperable than that is going to get us into deep water trying to define what happens in the general case when merging ranges of cells.

We should certainly make sure that 18.3.1.55 and L.2.2.13 are consistent, which they are not at present.

Francis



-----Original Message-----
From: Charlie Clark [mailto:charlie.clark at clark-consulting.eu] 
Sent: 08 August 2016 18:17
To: SC 34 WG4 <e-SC34-WG4 at ecma-international.org>; Rex Jaeschke <rex at rexjaeschke.com>
Subject: Re: DR-14-0014 - A Proposed Resolution

Am .08.2016, 17:54 Uhr, schrieb Rex Jaeschke <rex at rexjaeschke.com>:

> We still need the final words, but an intent has been proposed.

I cannot see how the proposed resolution does anything to promote interoperability. It specifically it ignores the problem of cells "created" just for styling purposes and sketches no roadmap for any potential improvements could resolve the problem:

  * overlays as in ODF
  * an extension to the format, such as the one I proposed

Interoperability would be relegated to reverse engineering application behaviour; this the raison d'être behind an open ECMA specification in the first place.

Charlie
--
Charlie Clark
Managing Director
Clark Consulting & Research
German Office
Kronenstr. 27a
Düsseldorf
D- 40217
Tel: +49-211-600-3657
Mobile: +49-178-782-6226