Problems with optional spans and r attributes in worksheet rows and cells

Charlie Clark charlie.clark at clark-consulting.eu
Tue Aug 7 13:22:56 CEST 2018


Hi everyone,

I'm currently doing some refactoring of my codebase and reviewing the  
specification. It seems to me that there is a problem with the current  
definition that allow both the spans attribute of a row element and the r  
attribute of a cell element to be optional.

If we take the current example for spans from § 18.3.1.73

  <sheetData>
     <row r="8" spans="4:6">
       <c r="F8">
         <v>1</v>
       </c>
     </row>
     <row r="9" spans="4:6">
       <c r="E9">
         <v>2</v>
       </c>
     </row>
     <row r="10" spans="4:6">
       <c r="D10">
         <v>3</v>
      </c>
     </row>
   </sheetData>

And then treat the r attribute of the cells as optional we get:

  <sheetData>
     <row r="8" spans="4:6">
       <c>
         <v>1</v>
       </c>
     </row>
     <row r="9" spans="4:6">
       <c>
         <v>2</v>
       </c>
     </row>
     <row r="10" spans="4:6">
       <c>
         <v>3</v>
      </c>
     </row>
   </sheetData>

How should such a block be interpreted? An enumerator would produce D4, D9  
and D10

The current narrative documentation says that:
"Optimization only, and not required. Specifies the range of non-empty  
columns (in the format X:Y) for the block of rows to which the current row  
belongs. To achieve the optimization, span attribute values in a single  
block should be the same."

But I think this is patently incorrect in this case and would suggest that  
the span refers to "column indices of the first and last cell of the  
current row". The description of the r attribute could be extended along  
the lines of "the r attribute may only be omitted if the parent row  
element contains a span element and contiguous cells."

The example could be thus expressed as:

  <sheetData>
     <row r="8" spans="6:6">
       <c>
         <v>1</v>
       </c>
     </row>
     <row r="9" spans="5:5">
       <c>
         <v>2</v>
       </c>
     </row>
     <row r="10" spans="4:4">
       <c>
         <v>3</v>
      </c>
     </row>
   </sheetData>

An enumerator would produce F8, E9 and D10 as in the original example and  
emphasise the optimisational character of the spans attribute, which  
obviates calculating the coordinates of every cell. But it does this, of  
course, come at the cost of a sparse matrix implementation.

However, having just tested the implementations with Excel 2016 for Mac I  
can report that the r attribute does seem to be essential but that Excel  
itself is happy with spans within a single "block" being different. The  
concept of a block seems implementation-dependent and not relevant here.  
Hence, I would suggest the following changes to § 18.3.1.73

"""
Optimization only, and not required. Specifies the range of non-empty  
columns (in the format X:Y) for the current row belongs where X refers to  
the index of the first cell in the row and Y refers to the index of the  
last cell in the row.

[Note: this is an optimization, and is purely optional. end note] Blank  
rows are not required to write out span values.
"""

And to $ 18.3.1.4

"""
r An A1 style reference to the location of this cell. For maximum  
interoperability this value should always be provided.
"""

Thoughts?

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


This message has been scanned for malware by Forcepoint. www.forcepoint.com


More information about the sc34wg4 mailing list