These "compatibility" settings solve no general problem. They are merely a museum of settings from previous versions of Microsoft Word. No allowance has been made for legacy settings from other applications. Better to have these be application-specific settings using the existing extensibility mechanisms of OOXML.

Proposed change: Remove the compatibility settings from OOXML.

2.15.3 [p1368]

te

Proposed Disposition of DIS 29500 Comment GB-0227 (Modified: 2008-01-13) We agree that the legacy compatibility settings only represent the settings from a single implementation. We will remove all of the compatibility settings that emulate legacy behaviors from their current location in the specification (Part 4, §2.15.3, pages 1369­1486), and place them into a new annex for deprecated features. Following the precedent set by other ISO standards (such as SQL’s ISO 9075:2003 Part 1 and C++’s ISO/IEC 14882:1998), we will make use of a new Annex that contains normative descriptions of all deprecated features. The intent of this Annex is to enable a transitional period during which existing binary documents being migrated to DIS 29500 can make use of those deprecated features to preserve their fidelity, while noting that new documents should not use them. Accordingly, the Conformance clause will also be changed to state that newly created documents (those not created by migrating existing binary documents) should not use deprecated features. All deprecated features will be removed from their current locations in the standard, but will be fully defined in this new Annex. The following settings will remain in Part 4, §2.15.3 and the text will be amended to note that they are for *language* compatibility, and, as such, are appropriate for use in new documents: doNotLeaveBackslashAlone (Part 4, §2.15.3.16, page 1,397) doNotExpandShiftReturn (Part 4, §2.15.3.15, page 1,396) balanceSingleByteDoubleByteWidth (Part 4, §2.15.3.7, page 1,379) applyBreakingRules (Part 4, §2.15.3.4, page 1,375) adjustLineHeightInTable (Part 4, §2.15.3.1, page 1,369) ulTrailSpace (Part 4, §2.15.3.55, page 1,469) spaceForUL (Part 4, §2.15.3.43, page 1,446) To make this clear the following text replaces the text introducing compatibility settings in Part 4, §2.15.3, page 1,368, lines 19­41: 2.15.3 Language Compatibility Settings The last group of settings in WordprocessingML are language compatibility settings. Language compatibility settings are optional settings used to specify changes appropriate to a subset of languages, but not usually appropriate in others. [Example: The doNotLeaveBackslashAlone setting changes the visual appearance of a specific character to match user expectation based on a historical use of that character in some code pages ­ users who have used those code pages would expect one value; those who have not would expect another. end example]. The behavior of each setting is fully defined in this sub-clause. If language compatibility settings are needed, they are stored in the Document Settings part. [Note: Although these settings can be applied in any WordprocessingML document, they are often applied when the document is created in one of the following contexts. In the case of ja-JP, ko-KR, zh-CN, zh-SG, zh-TW, zh-HK, zh-MO, ii-CN: doNotLeaveBackslashAlone doNotExapandShiftReturn balanceSingleByteDoubleByteWidth adjustLineHeightInTable ulTrailSpace spaceForUL In the case of th-TH, lo-LA, km-KH, bo-CN, hy-AM: applyBreakingRules end note] Similar Comments: BR-0008 , CL-0094 , KE-0024 , US-0099 , ZA-0011