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] XLIFF 2.0 Core


>> I'm not sure #2 applies. If they keep their data within a unique
>> toolset there is little advantage in using anything but some 
>> proprietary format it would seems. The only reason would if they 
>> want to be ready for #3.
>
> I use XLIFF format to keep the data used by my translation tools.
> That's case #2 in David's list.
> By using XLIFF as internal data format, there is no need to 
> export/import anything for exchanging data with another tool 
> (case #3), the data is ready to use.

Like I said: "The only reason would be if they want to be ready for #3."
A good reason certainly, and if a tool like Swordfish and Trados Studio can do it, more power to Rodolfo and Andrew :)


But I still think #2 is not a good use case for designing XLIFF:
XLIFF is an exchange format not an internal data format, or for native storage format.

One potential issue with using any exchange format as an internal data format is that the exchange format may have to provide features or follow some structures that may not be the most efficient for internal data.

In other words, there may be conflicts of interest between XLIFF as exchange format and XLIFF as internal format.

Internal data need to be tailored for the feature set the tool provides, for speed, simplicity, etc. While the exchange formats should favor interoperability, which means possibly support for features not implemented by some tools, which means not necessarily the best structure for all tools.

That is OK because exchange formats are normally converted/mapped to the tool-specific internal data format. So such tool pays the interoperability price only when it imports/exports, but its normal behavior is not affected.

But when that conversion buffer is absent, the tool is constantly and directly exposed to any aspect of the format that can be an impediment for its internal workings. In other words, parts of the exchange format may become drawbacks and hindrances for the performance of the tool.

And that, when working on defining the format, may lead to the danger of favoring the internal data aspect rather than the exchange format aspect, to favor some features over others, etc. That's why I think #3 is a good use case and #2 is not: XLIFF shouldn't care what happens within a specific tool, it should care only about working between tools.

This said, I know people like Rodolfo and Andrew are perfectly capable of having the discipline to separate both aspects and always favor exchange/interoperability over internal data when working in the context of the TC.

-ys




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