Sustainability of Digital Formats: Planning for Library of Congress Collections

The Strict variant of XLSX disallows a variety of elements and attributes that are permitted in the more common Transitional variant (XLSX/OOXML_2012). The markup for the Strict variant is essentially a subset of markup for the Transitional variant, but the schemas use different namespaces and are distributed separately in complete form.

The Strict variant of XLSX described here was introduced during the standardization in ISO/IEC 29500 in 2008 with the intention of excluding features included in ECMA-376, Edition 1 that were present simply to handle bugs and features of earlier spreadsheet applications. The intent of the split of the markup specification into Strict (Part 1) and Transitional (Part 4) was that applications would create new documents in the Strict variant; however, in practice, pressure for backwards compatibility has meant that most new files are marked up by applications using the Transitional namespace even if they use no features that are incompatible with the Strict specification.

Among the key differences between the Strict variant and the Transitional variant are:

• Use of VML (Vector Markup Language) for graphics is not permitted in XLSX Strict. All graphics, for example in charts, are represented using DrawingML.
• Characters in XLSX Strict are based on UNICODE. Other character sets and codepage technologies are not permitted.
• To comply with XLSX Strict, elements and attributes with deprecated names that use "left" and "right" in relation to start and end of text must be replaced by substitutes that are neutral in relation to the direction of text.
• Legacy techniques for protecting workbooks and their contents are disallowed in XLSX Strict.
• XLSX Strict has a value type for cells of date, using the Complete, Extended Format Calendar representations in ISO 8601. For reasons of backwards compatibility, this typed use of ISO 8601 dates is not permitted in XLSX Transitional. See Notes below.
• XLSX Strict does not permit the use of representations for drawing elements and attributes where percentages used to specify scaling and positioning are represented as integers outside the range 0-100. This technique was formerly used for performance reasons.

For discussion of other aspects of the Strict XLSX format, see the description of the more common Transitional variant of XLSX, XLSX/OOXML_2012.

ISO/IEC 29500-1, Information technology -- Document description and processing languages -- Office Open XML File Formats -- Part 1: Fundamentals and Markup Language Reference. Latest version (dated 2016 as of February 2017) is available from ISO/IEC Publicly Available Standards.

All editions of the OOXML standards as published by ECMA are available from ECMA-376: Office Open XML File Formats. See Notes below for version chronology.

The Strict variant of XLSX does not appear to be widely widely used as of February 2017, although support has been added to several applications in recent years.  The ability to read Strict XLSX files was first implemented by Microsoft in Excel 2010; in Windows Office, the ability to write Strict files as an option was added in Excel 2013 and is available in Excel 2016 and Office 365.  Office for Mac 2011 could neither read nor write Strict files.  The original release of Office for Mac 2016 could read but not write Strict files; more recent versions of Office for Mac have a setting to always use the Strict variant for saving XLSX files.

Feature Comparison Versions of LibreOffice since 4.2.3 can read Strict XLSX files. The Feature Comparison provided by LibreOffice for version 5.3 (released in early 2017) indicated that Strict XLSX files could be read but not written. The existence in 2017 of Support OOXML strict export as a project on a to-do list for LibreOffice suggested that this capability might be introduced before long. However, in December 2020, the Feature Comparison still indicated that Libre Office (version 7.0) could not write Strict XLSX files. A test using LibreOffice 5.2 confirmed that XLSX files written by that application were always in the more common Transitional form, regardless of which of two .xlsx options is chosen from the dropdown menu in the Save As feature. Two options were presented in LibreOffice because of a few small differences found in some files produced by Microsoft Office, particularly by Office 2007. See Useful References below.

Whether the Strict version of XLSX is more widely used in the future will likely depend on whether pressure on software vendors from governments for its adoption outweighs market pressure, which currently seems to favor backwards compatibility.

The compilers of this resource are not aware of any spreadsheet applications other than Microsoft products that can create the Strict variant of XLSX (as defined in Part 1 of the ISO/IEC 29500 standard). Tests in February 2017 indicated that Google Sheets and Libre Office (version 5.2) both created new documents in the Transitional variant, as indicated by the namespace declarations, even when the document includes no elements or attributes not present in the Strict versions of the schemas. This corresponds to the default behavior of Microsoft products.

Comments welcome.

See the more common Transitional form of XLSX, XLSX/OOXML_2012 and OOXML Format Family.

See the more common Transitional form of XLSX, XLSX/OOXML_2012.

See the more common Transitional form of XLSX, XLSX/OOXML_2012.

Accessibility Features

See OOXML Format Family for web accessibility information.

See the more common Transitional form of XLSX, XLSX/OOXML_2012.

See the more common Transitional form of XLSX, XLSX/OOXML_2012.

See the more common Transitional form of XLSX, XLSX/OOXML_2012.

See the more common Transitional form of XLSX, XLSX/OOXML_2012.

Textual and serial numeric representations of dates and times: In the Strict variant of XLSX, dates may be stored using textual forms specified in the ISO 8601 standard. Late in the ISO standardization process for OOXML, a proposal was made to adopt the ISO 8601 format for dates and times in spreadsheets. Dates and times in spreadsheets have usually been stored as numbers (sometimes termed "serial date-time" values), which use less space in memory or files, are convenient for common date-based calculations, and easily presented in a user-specified display format (following local conventions and using different scripts). The experts present at the ISO 29500 Ballot Resolution Meeting where votes were held on the outstanding proposals for the OOXML format were primarily experts in XML and in textual documents rather than with spreadsheets (see Why do we need serial dates in the Transitional form of IS 29500?, a 2009 blog post). The details of the proposal as approved had several shortcomings, recognized by spreadsheet experts once ISO 29500:2008 was published and software developers began to build tools. Firstly, no existing applications would be able to recognize and handle dates in the ISO 8601 format if they were included in XLSX Transitional files, as permitted by the published standard. See, for example, Losing data the silent way - ISO8601-dates. Since the intent of the Transitional variant of ISO 29500 was to be compatible with the existing corpus of .xlsx documents and the applications designed to handle them, an amendment to Part 4 to disallow ISO 8601 dates in the Transitional variant was introduced. Secondly, ISO 8601 is a very flexible format, and any use in a context that aims at interoperability needs to be specific about which particular textual string patterns are expected for dates and times. An amendment to specify particular string patterns for use in XLSX Strict, selected from the variety allowed by ISO 8601, was introduced as an amendment to Part 1. The associated amendments to Parts 1 and 4 were approved in December 2011 and incorporated into ISO 29500:2012. The changes were almost entirely in the text of the standard, with minimal changes to the schemas for SpreadsheetML, apart from disallowing the date cell-type in XLSX Transitional. The compilers of this resource are not aware of any SpreadsheetML implementations that would have generated XLSX Transitional files with dates in the ISO 8601 textual form that is no longer compliant with ISO 29500-4. Comments welcome.

The Strict variant of XLSX can contain dates in a textual form, using the Complete, Extended Format of ISO 8601, as specified in subclause 18.17.4 Dates and Times of ISO/IEC 29500-1:2011-2016. However, operations such as determining the number of years, days, minutes, or seconds between two date/time values, will usually be done using "serial date-time values," i.e., numbers that represent days relative to a base date. For this reason, the use of serial date-time values has been common in spreadsheets and other applications where dates are used as the basis for computation. Subclauses 18.17.4.1-3 of ISO/IEC 29500-1 discuss conversion between the two representations for dates.

See also the more common Transitional form of XLSX, XLSX/OOXML_2012.

For chronologies of the OOXML standard and for versions of Microsoft Office, see OOXML_Family. See also the more common Transitional form of XLSX, XLSX/OOXML_2012.