OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xliff] Proposal for Additional Segmentation Support Attributes

Title: Message

Hi David,


Thank you for your feedback, much appreciated!

See my comments below.





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: Magnus Martikainen [mailto:Magnus@trados.com]
Sent: Tuesday, March 08, 2005 7:27 PM
To: xliff
Subject: [xliff] Proposal for Additional Segmentation Support Attributes

Hi all,


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:




Best regards,

Magnus Martikainen

on behalf of the XLIFF Segmentation Subcommittee

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]