Hi John:
On your responses that are not embodied in Yves':
>We could become bogged down in a discussion of schemas when the work at hand is to approve or improve the current spec; with the multiplicity of schemas we could spend months on this topic alone. It is a good sub-committee discussion.
I suggest that we be agnostic, and deal with W3C, RELAX NG and Schematron. That way there is no need to discuss and decide on which to favour.
>The
assumption is that the target and source will both be encoded the same.
Usually in UTF-8. However, some mechanism for indicating a different
encoding in the target may be useful.
It's actually not possible to use the same character map for many languages. If you were to presume ANSI 1951 for all languages, you would limit XLIFF's application to ISOLatin 1 - 4 character sets. That bars Arabic, Chinese, Thai, Japanese and Korean, as well as the Cyrillic character sets, and other slavic languages. These languages represent very important markets for producers of goods, and they need to render the translated text for those languages. I urge that the spec would have the capability to deal with this in it's first iteration.
>The strongest
argument against multilingual XLIFF (more than one target language) was
the versioning problem. It would be too difficult to keep the languages
in sync.
I don't see a problem. Each language translation job becomes a separate project, once the translatable text strings have been extracted. They are merged back individually into the document structure file to produce the finished document in each language. Please see my communication with Yves on the issue of multiple target languages.
Regards,
David Leland
***********************************************************
jreid@novell.com wrote on 1/24/02 5:54:34 AM
************************************************************
Hi All,
A review of the spec may clear up some of the points better than this
discussion. I understand it wasn't easily available before our meeting
and some may not have had a chance to review it. I would hope that those
that haven't already done so to read it. It is now posted at our TC
website on OASIS.
I would like to elaborate a little on Yves's answers, as follows.
>>> Yves Savourel 1/23/02 4:56:16 PM >>>
Thanks for posting those comments David.
I'll try to answer a few of them. Not having working together yet there
is
maybe some terms we don't use the same way: if I'm not clear, please,
let me
know and I'll try to re-formulate.
> 1. document validators - we should have support for W3C Schema,
Schematron
and RELAX NG, as well as DTD.
I agree that we should have different ways to specify XLIFF so
different
people using different tools can have easy access to it. We can
probably
generate some of those schemas (or at leats a base to work from) from
the
DTD using converters as Christain showed me yesterday. I guess we
should
open the discussion on what schemas to use besides the DTD.
This isn't a weakness in the spec; the spec simply describes the
dictionary. The DTD and schema are artifacts of the spec. It is in the
charter to create a schema; the schema type is unspecified. We could
become bogged down in a discussion of schemas when the work at hand is
to approve or improve the current spec; with the multiplicity of schemas
we could spend months on this topic alone. It is a good sub-committee
discussion.
-----
> 2. Does not have entities for EXTRACT and MERGE.
-----
I'm not sure I understand the note. Could you explicit what you call
'EXTRACT' and 'MERGE'? Maybe the following description of XLIFF with
regard
to extraction and merging will help:
An XLIFF document stores initially the result of an extraction. The
original
input is split into 2 main streams: the localizable data are in the
content
of