[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] Simplified XLIFF element tree
Hi,
For the core/minimal XLIFF I would go for an even simpler model than Rodolfo's:
-- I think segmentation is too important to not be part of the core structure of XLIFF, and the representation as extra info like it is the case in 1.2 (because of the need to be backward compatible with 1.1) is not adequate. It does not mean a file must always be segmented, just that representing a segmented content must be simple and the processing of segmented vs un-segmented content should be seamless. For simplicity I've represented this as <part> in the tree below, but it would be whatever structure we would end up with.
-- I wouldn't put all the alt-trans data in the core. It corresponds to specific features that are not core to represent extracted text.
-- I would select only essential parts for the core, and therefore not include the skeleton since it's not something essential for the extracted data (i.e. one can merge without using the XLIFF <skel> data, and ,skel> is really tool-specific anyway).
-- I would not reduce the XLIFF namespace to the core. Just declare as core a subset of element/attributes of the namespace.
<xliff version1 >1
|
+--- <file original1 source-language1 datatype1 >+
|
+--- <body>1
|
+--- <group id1 resname? restype? >*
| |
| +--- [trans-unit]*
|
+--- <trans-unit id1 resname? restype? >*
|
+--- <source >1
| |
| +--- <part id? >+
| |
| +--- [inline markup]*
|
+--- <target >?
|
+--- <part id? >+
|
+--- [inline markup]*
Cheers,
-ys
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]