Hi Yves, Here's a written version of the treatment of data category 'datatype' which I proposed during the TC conference call on 23 July 2002. The proposal tries to touch the status quo, the most relevant parts of our discussion, and the suggested change for XLIFF 1.1. Best, Christian --- Status Quo (from XLIFF 1.1 WD): ------------------------------- Data type - The datatype attribute specifies the kind of text contained in the element. Depending on that type, you may apply different processes to the data. Value description: Text. The recommended values for the datatype attribute are defined in the XLIFF Values schema as the datatypeValueList type as follow (this list is not exhaustive): - cdf = Channel Definition Format. - cpp = C and C++ style text. - html = HTML, DHTML, etc. - interleaf = Interleaf documents. - java = Java, source and property files. - javascript = JavaScript, ECMAScript scripts. - lisp = Lisp. - mif = Framemaker MIF, MML, etc. - pascal = Pascal, Delphi style text. - plaintext = Plain text. - rtf = Rich Text Format. - sgml = SGML. - vbscript = Visual Basic scripts. - winres = Windows resources from RC, DLL, EXE. - xml = XML. Default value: Empty string. Used in: <file>, <group>, <trans-unit>, <alt-trans>, <sub>. Discussion: ----------- 1. We are under the impression (and have stated this explicitly in the WD) that the list of proposed values is incomplete. 2. Some of the the values may deserve different names (see for example the proposal related to handling Win32 Resources in XLIFF
http://lists.oasis-open.org/archives/xliff/200206/msg00029.html ) where an alternate/additional name for 'winres' is suggested. 3. We fear that various issues arise if new values are added to the list as needed/ in a non-systematic way. For example the introduction of 'java-resource-list' and 'java-resource-bundle' would 'override' the 'java' value (see the example from the discussion of formalized extensibility
http://lists.oasis-open.org/archives/xliff/200206/msg00000.html ). 4. For reasons of backward compatibility, we would like to change as little as possible. 5. Using mime-types from RFC 2046 (see
http://www.faqs.org/rfcs/rfc2046.html ) might be an alternative. Suggested Change: ----------------- 1. We add the value 'mime-type' to the list of proposed values. 2. We introduce a new data category 'mime-type'. This new data category could be formalized as an optional attribute. The values of the new data category follow RFC 2046. 3. We add clauses like the following to the WD: a) Whenever the value 'mime-type' is used for 'datatype', the new data category/ optional attribute 'mime-type' has to be present as well. It is considered an error if the the new data category/optional attribute 'mime-type' is used in cases where the value for 'datatype' is not 'mime-type'. b) The use of the attribute 'datatype' is deprecated. Use 'mime-type' instead.