From owner-incits-v1@incits-v1.org Mon Jun 18 19:04:26 2007 Date: Mon, 18 Jun 2007 19:03:37 -0700 (PDT) From: jon.bosak@sun.com Subject: INCITS-V1: AlternativeFormat-Durusau-5 Sender: owner-incits-v1@incits-v1.org To: incits-v1@incits-v1.org Reply-to: incits-v1@incits-v1.org X-PMX-Version: 5.2.0.264296 X-Authentication-warning: jurassic-x4600.sfbay.sun.com: bosak set sender to jon.bosak@sun.com using -f The problem pointed to in comment Durusau-5 seems to follow as a consequence of the previously noted lack of a standard mapping between DIS 29500 and the legacy formats for which it claims to provide a path forward into XML, and Patrick rightly points to the implications for legacy formats. In this case, however, there appear to be larger issues at play as well. In Section 11.3.1 of Part 1, the content type of Alternative Format Import Part is defined as "any content, support for which is application-defined." Needless to say, this covers a lot of possibilities. The requirement for conformant consuming software is equally broad: "A WordprocessingML consumer shall treat the 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 in WordprocessingML format." I see two major problems with this formulation. 1. It assumes that the arbitrary Alternative Format can, in fact, be represented in DIS 29500 format. This is, of course, impossible to guarantee in the general case. XML alone (one of the possibilities informatively listed in Section 11.3.1) is capable of denoting an unlimited number of imaginable formatting semantics that are beyond the representational capabilities of this or any other particular version of DIS 29500. 2. Even if we ignore this problem and assume that DIS 29500 is capable of supporting every possible feature of every possible input word processing format, both now and in the future, DIS 29500 provides no mappings that would enable consuming software to properly and verifiably conform to the requirement that it "shall treat the contents of such legacy text files as if they were formatted using equivalent WordprocessingML." Without standard mappings, there is no mechanism for establishing whether the output form is "equivalent" to the input. In other words, conforming applications are required ("shall treat," "shall emit") to implement behavior whose conformance to the specification is impossible to establish. Since it is self-evident that an ISO standard cannot normatively require behavior conformance to which cannot be determined, this requirement cannot be part of DIS 29500 as eventually approved. I can think of two ways to resolve this. 1. Section 11.3.1 can be rewritten to explicitly and exhaustively list the formats to which its requirements apply, and then mappings can be provided between each such format and the DIS 29500 format in detail sufficient to determine in every case whether a conformant application has met those requirements, or 2. Section 11.3.1 can be rewritten to relax its requirements and turn them into some kind of meaningful guidelines, abandoning the fiction that all possible input formats can be represented in the DIS 29500 format with perfect fidelity. Perhaps others can think of different solutions. Jon