DR 16-0007 - SML: omissions and inconsistencies in the specification of attributes

[caroline arms]

I just had time to get started through the excellent work Francis has done.

So far, my inclination would be to go along with the proposals Francis
has made -- while also acknowledging that schema changes could
possibly result in existing documents becoming non-conformant.

I have just been through the first few -- and then was called away to
get something else important done for LoC before heading to Maine
tomorrow.

See notes below.  My apologies for having to miss the call

Caroline

§18.2.2 calcPr (@forceFullCalc) (complex type: CT_CalcPr)

 MS-OI29500, subsection 2.1.562 (page 232) includes the following note:

 a. The standard does not specify a default value for the
forceFullCalc attribute.

 Excel uses a default value of false for this attribute.

 There doesn’t appear to be any mechanism in the Excel 2016 user
interface for specifying a value for this attribute. By default, Excel
2016 doesn’t save an explicit value for this attribute, and nor does
LibreOffice Calc.

 Proposed resolution: Add default value false to schema and prose,
having first checked that the other major implementation, LibreOffice
Calc, either uses the same default value or ignores this feature.

CRA:  The proposed resolution seems fine to me in general.  Are there
other implementations worth checking, such as Google's?

====
§18.2.7 ext (@uri) (complex type: CT_Extension)

There is no note on this attribute in MS-OI29500. The attribute is
clearly optional, and its omission simply implies that there is no
version or application information available for this extension, or it
is implied by the content of the <ext> element.

Proposed resolution: For clarity, add use=”optional” to the schema,
and change the description of the attribute @uri in prose to read: “If
present, a token to identify version and application information for
this particular extension”. However, it may be simpler to take no
action.

CRA:  The proposed resolution looks good to me.  Assuming we make any
changes as a result of this DR, I don't see any problems with making
the changes Francis suggests "for clarity."

====

§18.2.22 smartTagType (@name) (complex type: CT_SmartTagType)

MS-OI29500, subsection 2.1.577 (page 239) includes the following note:

d. The standard states that the name attribute is optional.

 Excel requires this attribute.

 So far as I can judge, this is a feature that is supported fully
(i.e. susceptible to user control) only by Excel 2007. However, given
its intended use in Excel 2007, it doesn’t make sense for a smart tag
not to have a name, so I believe that the schema is at fault and this
attribute should be required.

 Proposed resolution: Change the schema to make this attribute
required. No change to prose.

CRA:  I'm inclined to agree with Francis.
I see that LibreOffice has a "smart tag" feature too.
    https://help.libreoffice.org/Writer/Using_Smart_Tags
Is it related?  Is there any chance that a DOCX file created by
LibreOffice would use this element without the attribute?  Smart Tags
in LibreOffice are extensions to the application.

====

§18.3.1.10 cfRule (@type) (complex type: CT_CfRule)

MS-OI29500, subsection 2.1.592 (page 247) includes the following note:

a. The standard implies that the type attribute is optional.

Excel requires this attribute.

I don’t believe that use of this element makes sense without @type
being specified, since it specifies the type of rule to be used to
determine whether a conditional formatting rule should be applied to a
cell or not. Without specifying the rule type, the condition cannot be
determined.

Proposed resolution: Add use=”required” to the schema. No change to prose.

CRA: Again, my inclination is to agree with Francis.




On Tue, Aug 22, 2017 at 11:33 AM, Francis Cave <francis at franciscave.com> wrote:
> Sorry, I missed changing one reference to MS-OE376 – highlighted in cyan.
>
>
>
> Francis
>
>
>
>
>
>
>
> From: Francis Cave [mailto:francis at franciscave.com]
> Sent: 22 August 2017 16:05
> To: 'SC 34 WG4' <e-SC34-WG4 at ecma-international.org>
> Subject: RE: DR 16-0007 - SML: omissions and inconsistencies in the
> specification of attributes
>
>
>
> Dear all
>
>
>
> Oops! I have discovered that I should have been referencing notes in
> Microsoft document MS-OI29500, not in MS-OE376. Please accept my apologies
> for this oversight. I have adjusted the references below accordingly, and
> have also corrected some typos. Changes highlighted in yellow.
>
>
>
> Kind regards,
>
>
>
> Francis
>
>
>
>
>
> From: Francis Cave [mailto:francis at franciscave.com]
> Sent: 16 August 2017 19:09
> To: 'SC 34 WG4' <e-SC34-WG4 at ecma-international.org>
> Subject: DR 16-0007 - SML: omissions and inconsistencies in the
> specification of attributes
>
>
>
> Dear all
>
>
>
> I have finally started making progress on attempting to find a resolution to
> this DR. My thanks to Rich McLain and Aarti Nankani for guiding me to the
> right place in the Standards Support section of the MSDN Library.
>
>
>
> The following document is relevant to resolution of this DR:
>
>
>
> MS-OI29500: Office Implementation Information for ISO/IEC 29500 Standards
> Support
>
>
>
> Much the same information can be found in the following document, but
> relating to ECMA 376:
>
>
>
> MS-OE376: Office Implementation Information for ECMA-376 Standards Support
>
>
>
> The following document is presumed not to be relevant, as it is only
> concerned with extension elements that are specific to Office and therefore
> not documented in the standard:
>
>
>
> MS-XLSX: Excel (.xlsx) Extensions to the Office Open XML SpreadsheetML File
> Format
>
>
>
> Note that MS-OE376 refers to the ECMA-376 version of the standard, so the
> numbering of clause references in it differs from that in 29500-1. In what
> follows I have used 29500-1 clause reference numbering throughout.
>
>
>
> MS-OI29500 specifies requirements/constraints on attribute values in a
> number of additional cases. For example, where Excel requires use of an
> attribute that the standard specifies to be optional, I think that would be
> worth reviewing. Some of these are, no doubt, specific to the Office
> implementation, but ideally these should be checked to see which should
> apply to all implementations.
>
>
>
> Here is a list of element-attribute combinations not included in the DR for
> which MS-OI29500 states that Excel requires the attribute but it is
> specified to be optional in the standard:
>
>
>
> §18.2.14 functionGroup (@name) (complex type:  CT_FunctionGroup)
> §18.2.22 smartTagType (@namespaceUri) (complex type: CT_SmartTagType) –
> @name is covered by the DR
> §18.3.1.69 pivotSelection (@r:id) (complex type: CT_PivotSelection)
> §18.3.2.1 colorFilter (@dxfId) (complex type: CT_ColorFilter)
> §18.5.2.3 xmlCellPr (@uniqueName) (complex type: CT_XmlCellPr)
> §18.10.1.6 cacheHierarchy (@caption) (complex type: CT_CacheHierarchy)
> §18.10.1.47 kpi (@caption) (complex type: CT_PCDKPI)
> §18.11.1.3 nc (@r) (complex type: CT_Cell)
>
>
>
> The note in MS-OI29500 regarding @r on §18.11.1.3 nc (New Cell Data) has
> caused me to look at what MS-OI29500 has to say about @r on §18.3.1.4 c
> (Cell):
>
>
>
> c. The standard makes @r optional in the schema, but the prose does not
> explain the meaning of the default behavior.
>
>
>
> If this attribute is not specified, the cell shall be located in the column
> with the index that is 1 greater than that of the previous cell in the
> parent row collection. If this attribute is not specified and the cell is
> the first c element in the parent row collection, the cell shall be located
> in the first column.
>
>
>
> Do we need to document this default behaviour in the standard? See
> discussion below regarding omission of the attribute @r on §18.3.1.73 row.
>
>
>
> Here is a list of element-attribute combinations not included in the DR for
> which MS-OI29500 states that Excel uses a default value not specified by the
> standard:
>
>
>
> §18.2.2 calcPr (@calcId) (complex type: CT_CalcPr) – default value 0
> §18.2.28 workbookPr (@defaultThemeVersion) (complex type: CT_WorkbookPr) –
> default value 0
> §18.3.1.10 cfRule (@rank) (complex type: CT_CfRule) – default value 0
> §18.3.1.33 dataValidations (@count, @xWindow, @yWindow) (complex type:
> CT_DataValidations) – in each case default value 0
> §18.3.1.52 inputCells (@numFmtId) (complex type: CT_InputCells) – default
> value 0
> §18.3.1.68 pivotArea (@field) (complex type: CT_PivotArea) – default value
> –1
> §18.3.1.78 selection (@activeCell) (complex type: CT_Selection) – default
> value A1
> §18.3.1.93 tabColor (@auto) (complex type: CT_TabColor) – default value
> false
> §18.3.2.4 dateGroupItem (@day, @month) (complex type: CT_DateGroupItem) –
> default value 1 [Note: @year is required]
> §18.3.2.4 dateGroupItem (@hour, @minute, @second) (complex type:
> CT_DateGroupItem) – default value 0
> §18.5.1.2 table (@connectionId) (complex type: CT_Table) – default value 0
> [Nit note: The description of this attribute contains poorly-worded
> normative text: “This shall only be used for tables that are based off of
> xmlupon XML maps.”]
> §18.8.1 alignment (@horizontal, @vertical) (complex type: CT_CellAlignment)
> – default values of general and bottom respectively
> §18.8.1 alignment (@indent, @relativeIndent, @textRotation) (complex type:
> CT_CellAlignment) – in each case default value 0
> §18.8.1 alignment @justifyLastLine, @readingOrder, @shrinkToFit, (@wrapText)
> (complex type: CT_CellAlignment) – in each case default value false
> §18.8.4 border (@diagonalDown, @diagonalUp) (complex type: CT_Border) – in
> each case default value false
> §18.8.33 protection (@hidden @locked) (complex type: CT_CellProtection) –
> default values of false and true respectively
> §18.10.1.33 filter (@iMeasureFld) (complex type: CT_PivotFilter) – default
> value 0
> §18.10.1.57 mp (@pPos, @pLen, @nameLen) (complex type: CT_MemberProperty) –
> in each case default value 0
> §18.10.1.69 pivotField (@dataSourceSort, @numFmtId) (complex type:
> CT_PivotField) – default values of false and true respectively
> §18.10.1.73 pivotTableDefinition (@applyAlignmentFormats,
> @applyBorderFormats, @applyFontFormats, @applyNumberFormats,
> @applyPatternFormats, @applyWidthHeightFormats, @dataPosition) (complex
> type: CT_pivotTableDefinition) – in each case default value 0
> [Nit note: inconsistency in name of complex type – should ideally be
> CT_PivotTableDefinition – probably not worth correcting, unfortunately…]
> §18.10.1.74 pivotTableStyleInfo (@showColHeaders, @showColStripes,
> @showRowHeaders, @showRowStripes) (CT_PivotTableStyle) – in each case
> default value 0
> §18.10.1.88 set (@count) () (complex type: CT_Set) – default value
> 4294967295
> §18.11.1.1 header (@maxRId, @minRId) (complex type: CT_RevisionHeader) –
> Excel uses a default value 0 for @minRId, and a default value equal to the
> current value of @minRId for @maxRId
> §18.11.1.9 rcc (@numFmtId) (complex type: CT_RevisionCellChange) – default
> value 0
> §18.16.1 DataBinding (@FileBinding) (complex type: CT_DataBinding) – default
> value false
>
>
>
> More work for a further DR here, I think…
>
>
>
> Resolutions are indicated below for each of the first ten elements listed in
> the DR. For convenience, I have list the elements that remain to be
> considered at the end.
>
>
>
> Francis
>
>
>
>
>
>
>
>
>
> §18.2.2 calcPr (@forceFullCalc) (complex type: CT_CalcPr)
>
>
>
> MS-OI29500, subsection 2.1.562 (page 232) includes the following note:
>
>
>
> a. The standard does not specify a default value for the forceFullCalc
> attribute.
>
>
>
> Excel uses a default value of false for this attribute.
>
>
>
> There doesn’t appear to be any mechanism in the Excel 2016 user interface
> for specifying a value for this attribute. By default, Excel 2016 doesn’t
> save an explicit value for this attribute, and nor does LibreOffice Calc.
>
>
>
> Proposed resolution: Add default value false to schema and prose, having
> first checked that the other major implementation, LibreOffice Calc, either
> uses the same default value or ignores this feature.
>
>
>
> §18.2.7 ext (@uri) (complex type: CT_Extension)
>
>
>
> There is no note on this attribute in MS-OI29500. The attribute is clearly
> optional, and its omission simply implies that there is no version or
> application information available for this extension, or it is implied by
> the content of the <ext> element.
>
>
>
> Proposed resolution: For clarity, add use=”optional” to the schema, and
> change the description of the attribute @uri in prose to read: “If present,
> a token to identify version and application information for this particular
> extension”. However, it may be simpler to take no action.
>
>
>
> §18.2.22 smartTagType (@name) (complex type: CT_SmartTagType)
>
>
>
> MS-OI29500, subsection 2.1.577 (page 239) includes the following note:
>
>
>
> d. The standard states that the name attribute is optional.
>
>
>
> Excel requires this attribute.
>
>
>
> So far as I can judge, this is a feature that is supported fully (i.e.
> susceptible to user control) only by Excel 2007. However, given its intended
> use in Excel 2007, it doesn’t make sense for a smart tag not to have a name,
> so I believe that the schema is at fault and this attribute should be
> required.
>
>
>
> Proposed resolution: Change the schema to make this attribute required. No
> change to prose.
>
>
>
> §18.3.1.2 autoFilter (@ref) (complex type: CT_AutoFilter)
>
>
>
> There is no note on this attribute in MS-OI29500. The attribute is clearly
> required, since data filtering is always applied to a specified range of
> cells. The absence of @use on the attribute declaration in the schema is
> possibly caused by a misunderstanding of the default value of @use on
> attribute declarations in XSD (see W3C XML Schema Part 1, section 3.2.2).
>
>
>
> Proposed resolution: Add use=”required” to the schema. No change to prose.
>
>
>
> §18.3.1.10 cfRule (@type) (complex type: CT_CfRule)
>
>
>
> MS-OI29500, subsection 2.1.592 (page 247) includes the following note:
>
>
>
> a. The standard implies that the type attribute is optional.
>
>
>
> Excel requires this attribute.
>
>
>
> I don’t believe that use of this element makes sense without @type being
> specified, since it specifies the type of rule to be used to determine
> whether a conditional formatting rule should be applied to a cell or not.
> Without specifying the rule type, the condition cannot be determined.
>
>
>
> Proposed resolution: Add use=”required” to the schema. No change to prose.
>
>
>
> §18.3.1.73 row (@r) (complex type: CT_Row)
>
>
>
> There is a note on this attribute in MS-OI29500 (limiting the value range –
> see subsection 2.1.641, note a, page 274), but no mention of the attribute
> being optional in the standard or how to interpret its omission. Given what
> MS-OI29500 says about how to interpret the omission of @r on §18.3.1.3 c
> (Cell), I have tested Excel’s ability to open a spreadsheet with @r omitted
> on rows. Excel will successfully open the spreadsheet in certain limited
> circumstances, e.g. the following opens without error and omission of @r on
> the second <row> element is taken to imply a value ‘2’:
>
>
>
>     <sheetData>
>
>         <row r="1">
>
>             <c r="A1">
>
>                 <v>1</v>
>
>             </c>
>
>         </row>
>
>         <row>
>
>             <c r="A2">
>
>                 <v>2</v>
>
>             </c>
>
>         </row>
>
>         <row r="5">
>
>             <c r="A5">
>
>                 <f>A1+A2</f>
>
>                 <v>3</v>
>
>             </c>
>
>         </row>
>
>     </sheetData>
>
>
>
> However, the values of @r on the <row> and <c> elements have to be
> consistent, and if the @r value on the cell in the second row is changed
> from ‘A2’ to ‘A3’, Excel reports an error, because the value of @r on the
> second <row> element is implied to be ‘2’.
>
>
>
> Proposed resolution: Add the following to the description of @r in prose:
>
>
>
> If this attribute is not specified, the row index shall be 1 greater than
> that of the previous row in the parent element. If this attribute is not
> specified and the row is the first in the parent element, the row index
> shall be ‘1’.
>
>
>
> We should also consider making a similar change to the description of @r on
> §18.3.1.3 c (Cell) (see above).
>
>
>
> §18.3.2.1 customFilter (@val) (complex type: CT_CustomFilter)
>
>
>
> There is no note on this attribute in MS-OI29500. The attribute @operator on
> the same element clearly only makes sense if @val is specified, and
> @operator has a default value equal. The absence of @use on the attribute
> declaration in the schema is possibly caused by a misunderstanding of the
> default value of @use on attribute declarations in XSD (see W3C XML Schema
> Part 1, section 3.2.2).
>
>
>
> Proposed resolution: Add use=”required” to the schema. No change to prose.
>
>
>
> §18.3.2.6 filter (@val) (complex type: CT_Filter)
>
>
>
> MS-OI29500, subsection 2.1.663 (page 283) includes the following note:
>
>
>
> a. The standard implies that the val attribute is optional.
>
>
>
> Excel requires this attribute.
>
>
>
> This element makes no sense if @val is omitted, since its purpose is to
> specify a filter criteria value. The absence of @use on the attribute
> declaration in the schema is possibly caused by a misunderstanding of the
> default value of @use on attribute declarations in XSD (see W3C XML Schema
> Part 1, section 3.2.2).
>
>
>
> Proposed resolution: Add use=”required” to the schema. No change to prose.
>
>
>
> §18.3.2.10 top10 (@filterVal) (complex type: CT_Top10)
>
>
>
> MS-OI29500, subsection 2.1.667 (page 284) includes the following note:
>
>
>
> b. The standard does not specify a default value for the filterVal
> attribute.
>
>
>
> Excel uses a default value of 0 for this attribute.
>
>
>
> Tests in Excel suggest that @filterVal simply preserves the lowest (if
> filtering top values) or highest (if filtering bottom values) value to be
> shown when opening the document. As such, its value is implied by the value
> of @val, @percent (if present) and the range of values being filtered. If
> @filterVal is omitted, Excel will simply re-calculate it when opening the
> document and store it when saving the document. If an incorrect value is
> inserted, Excel ignores but preserves the incorrect value until the filter
> is re-specified. I therefore don’t understand what is meant by the note in
> MS-OI29500 saying that Excel uses a default value of 0 for this attribute.
>
>
>
> I note in passing that the example given in the standard (pages 1716-1717)
> is incorrect, because <top percent=”1” val=”5” filterVal=”6”> implies the
> top 5 percent, not the top 10 percent as suggested in the prose.
>
>
>
> Proposed resolution: No change to the schema or normative prose, but I
> propose that the example be re-worded as follows:
>
>
>
> [Example: This example filters the first column by the top 105 percent of
> the values in that column. For all cells in the column whose value falls
> outside the top 105 percent of the value in that column, the rows
> corresponding to those cells are hidden from the view. In this example, if
> there are 6 cells in the range, containing 1, 2, 3, 4, 5, 6 respectively,
> all rows except the row containing 6 will be hidden.
>
>
>
> §18.5.1.5 tableStyleInfo (@showColumnStripes, @showFirstColumn,
> @showLastColumn, @showRowStripes) (complex type: CT_TableStyleInfo)
>
>
>
> MS-OI295006, subsection 2.1.679 (page 288) includes the following notes:
>
>
>
> b. The standard does not specify a default value for the showColumnStripes
> attribute.
>
>
>
> Excel uses a default value of false for this attribute.
>
>
>
> c. The standard does not specify a default value for the showFirstColumn
> attribute.
>
>
>
> Excel uses a default value of false for this attribute.
>
>
>
> d. The standard does not specify a default value for the showLastColumn
> attribute.
>
>
>
> Excel uses a default value of false for this attribute.
>
>
>
> e. The standard does not specify a default value for the showRowStripes
> attribute.
>
>
>
> Excel uses a default value of false for this attribute.
>
>
>
> LibreOffice preserves table styling in a spreadsheet prepared in Excel
> containing a table, but LibreOffice doesn’t use table styling and the user
> cannot create tables and can only remove them by removing the cells
> contained within it. In that sense, all the above defaults specified for
> Excel would also apply to LibreOffice. No other defaults make any sense from
> an interop perspective.
>
>
>
> Proposed resolution: Add default=“false” to each of the four attribute
> declarations in the schema.
>
>
>
>
>
> ELEMENTS IN DR 16-0007 NOT YET CONSIDERED
>
>
>
> The following 21 elements in the DR have yet to be considered:
>
>
>
> §18.8.7 cellStyle (@name) (complex type: CT_CellStyle)
>
>
>
> §18.8.34 rgbColor (@rgb) (complex type: CT_RgbColor)
>
>
>
> §18.10.1.2 b (@cp, @f, @u) (complex type: CT_Boolean)
>
>
>
> §18.10.1.8 calculatedItem (@formula) (complex type: CT_CalculatedItem)
>
>
>
> §18.10.1.21 d (@cp, @f, @u) (complex type: CT_DateTime)
>
>
>
> §18.10.1.27 e (@bc, @cp, @f, @fc, @in, @u) (complex type: CT_Error)
>
>
>
> §18.10.1.45 item (@x) (complex type: CT_Item)
>
>
>
> §18.10.1.50 m (@bc, @cp, @f, @fc, @in, @u) (complex type: CT_Missing)
>
>
>
> §18.10.1.51 map (@dimension, @measureGroup) (complex type:
> CT_MeasureDimensionMap)
>
>
>
> §18.10.1.60 n (@bc, @cp, @f, @fc, @in, @u) (complex type: CT_Number)
>
>
>
> §18.10.1.74 pivotTableStyleInfo (@showColHeaders, @showColStripes,
> @showLastColumn, @showRowHeaders, @showRowStripes) (complex type:
> CT_PivotTableStyle)
>
>
>
> §18.10.1.85 s (@bc, @cp, @f, @fc, @in, @u) (complex type: CT_String)
>
>
>
> §18.10.1.86 serverFormat (@culture, @format) (complex type: CT_ServerFormat)
>
>
>
> §18.10.1.92 tpl (@fld, @hier) (complex type: CT_Tuple)
>
>
>
> §18.13.1 connection (@name, @type) (complex type: CT_Connection)
>
>
>
> §18.13.3 dbPr (@command) (complex type: CT_DbPr)
>
>
>
> §18.13.5 olapPr (@rowDrillCount) (complex type: CT_OlapPr)
>
>
>
> §18.13.12 textPr (@characterSet) (complex type: CT_TextPr) – the attribute
> @codePage was moved to Part 4, but is still mentioned here and in §18.2.24
> webPublishing.
>
>
>
> §18.13.13 webPr (@url) (complex type: CT_WebPr)
>
>
>
> §18.14.1 cell (@r) (complex type: CT_ExternalCell)
>
>
>
> §18.14.15 definedName (@refersTo) (complex type: CT_ExternalDefinedName)
>
>