Arbitrary (in quality and quantity) alternative format content essentially undermines the effort of interoperable documents. It would be possible to re-package with minimal effort a legacy format document into a document which would be technically conformant to the present specification but would also be essentially useless for a consumer that is not aware of the legacy format.

Restrict the use of alternative format imports (eg, requiring a parallel import of a format conforming to this specification, somewhat like MIME’s multipart/alternative) and/or specify an explicit conformance level for customers to choose which would require producers to not only "black-box" legacy format content.

Part 1, section 11.3.1

ed

Proposed Disposition of DIS 29500 Comment DE-0150 (Modified: 2007-11-26) Agreed; these references are inappropriate; the following changes will be made in Part 1, §11.3.1: Page 28, Line 1, “Content Type” row Content Type: Any content, support for which is application-defined. [Note: Some examples of formats which might be supported include: Text = application/txt RTF = application/rtf HTML = application/html XML = application/xml end note] Page 28, lines 3-5 An alternative format import part allows content specified in an application-defined alternate format (HTML, MHTML, RTF, earlier versions of WordprocessingML, or plain text) to be embedded directly in a WordprocessingML document in order to allow that content to be migrated to the WordprocessingML format. Page 28, lines 15-17 A WordprocessingML consumer shall who understands the format of an instance of this part should treat the its contents of such legacy text files as if they were formatted using equivalent WordprocessingML, and if that consumer is also a WordprocessingML producer, it shall emit the legacy text contents of the part in WordprocessingML format. Similar Comments: CL-0040 , DE-0006 , DK-0101 , DK-0151 , DK-0156 , FR-0014 , GB-0041 , KE-0004 , MT-0005 , PH-0006 , US- 0033