RE: [xliff] Working Draft - data category 'datatype'

["Lieske, Christian" <christian.lieske@sap.com>]

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.

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com]
Sent: Freitag, 12. Juli 2002 21:50
To: XLIFF list
Subject: [xliff] Working Draft


Hi everyone,

Here is an updated version of the working draft for 1.1. The zip file
includes the schema for the core and the values.

I didn't include the proposal for <reformat> nor <tool> in it yet.

I'm still looking into how to allow extending attribute values. I suppose
you can define your own list of types and import the pre-defined one, but
that is akward for validation. It would be nice to fine a way to have to
change only imported files, so the reference to the main XSDs would remain
the same regardless whether or not you have your own extension.
I hope some of you have ideas for this, because I can see I'm running out...

Have a great week-end
-yves