Hi David,
Thank you for your feedback, much
appreciated!
See my comments below.
Regards,
Magnus
From:
David Pooley [mailto:dpooley@sdl.com]
Sent: Monday, March 14, 2005 3:48
AM
To: 'xliff'
Subject: RE: [xliff] Proposal for
Additional Segmentation Support Attributes
Some questions/observations:
[1] I didn't see any indication as to
whether the new attributes are mandatory or optional on the <group> and <trans-unit> elements.
[Magnus] They are optional. This is implied by the fact that
they have default values. However we can update the specifications to state this
explicitly too.
[2] As equivalent-translation is being set
at the <trans-unit>
level, this seems to impose the setting through all <alt-trans> elements. Is this
a good idea?
[Magnus] Good point. The intention with this attribute is to
allow a translator to indicate for a particular trans-unit that the
<target> content is not a direct translation of the <source>
content. As such it has no direct relation to the <alt-trans> elements,
and really only applies to the direct <source> and <target> in the
<trans-unit>. We could clarify this further in the documentation. Another
option that we can evaluate is whether the attribute could be moved to the
<target> element instead.
[3] Where did you envisage the
manipulation of the elements and attributes taking place? I don't see how they
can realastically be set by the original filter, unless it has detailed
linguistic knowledge or there's some information in the original file type that
can be used. Does this mean that it's the responsibility of the XLIFF editor to
change the DOM structure of the document? If so, I think this will need to be
documented in the specification.
[Magnus] I am not sure I understand the point you are trying
to make here. The attributes provide a means for annotating the XLIFF file with
potentially important information. It is up to individual tool implementations
if they wish to introduce such annotations. We can make no specific assumptions
about how such tools are implemented. The same applies for uses of other
attributes or other use of the <group> element. I don’t see why
this would be a problem. Could you please clarify?
[4] A minor point, I know, but is it
really necessary to have such long attribute names? As XLIFF documents are
potentially being sent to translators, this would seem to be bloating the file
size for someone who potentially is downloading with a modem :-)
[Magnus] In the process of designing this proposal we considered
some alternative names, but concluded that they all looked too cryptic. In
particular since these attributes represent information that is of great importance
it was a high priority for us to use names that clearly conveyed the
information. It may be some comfort to you to know that the situations in which
these attributes are required should with well working filters be very rare, that
they should only need to appear rather sparsely when they do appear, and that
the file content will compress very well when used with WinZip or similar
tools. I believe that the advantages clearly outweigh the disadvantages in this
particular case…
David
Pooley
Software Architect
SDL International
-----Original
Message-----
From: [mailto:Magnus@trados.com]
Sent: Tuesday, March 08, 2005 7:27
PM
To: xliff
Subject: [xliff] Proposal for
Additional Segmentation Support Attributes
The segmentation subcommittee has voted unequivocally to put
forward the proposal detailed below to the main XLIFF
committee regarding two additional attributes related to segmentation in
XLIFF files.
I would hereby like to request a formal review of the
proposal by the XLIFF Committee for its inclusion in the XLIFF draft
specification.
The following document explains the proposal and details
the proposed changes to the XLIFF specification:
http://www.oasis-open.org/apps/org/workgroup/xliff-seg/download.php/11725/seg-new-attributes.htm
on behalf of the XLIFF Segmentation Subcommittee