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] Metadata extensibility ballot

Yves, after reading your note, I decided to look at this in two ways:

1. Programmer view: Yves has a good point. When the embedded data becomes more than a simple data type or data structure, metaholder will not likely work too well.
2. Practitioner view: That is not necessarily a concern (e.g. QA error) for some, what happens if I DO NOT care about it? To include custom name space would now introduce additional complexity into my env that I really just want it to be passed thru and ignored.

So, possible options:
1. Have a very well-defined scope of what meta data can be expected in the metaholder and nothing beyond that.
2. The use of custom namespace cannot be used within the <source> and <target> elements directly to keep parsing simple if one does not care.

Having said this is not to suggest we put back the "both" option in the ballot because my vote stands. I have no need of using custom name space within near term in our process or tooling env. I do not see it a necessity to me.

Best regards,

Helena Shih Chapman
Globalization Technologies and Architecture
+1-720-396-6323 or T/L 938-6323
Waltham, Massachusetts

From:        Yves Savourel <ysavourel@enlaso.com>
To:        <xliff@lists.oasis-open.org>
Date:        06/14/2012 08:34 AM
Subject:        RE: [xliff] Metadata extensibility ballot
Sent by:        <xliff@lists.oasis-open.org>

Hi Kevin, all,

> - Projects like MultilingualWeb-LT are working on many
> data categories that are related to localization process.
> That is just one example. The point is: XLIFF does not work
> in a vacuum, and 2.0 needs to be flexible enough to take
> into account other standards that are relevant.
> Namespaces are the perfect mechanism for this.

I'd like to expend on ITS 2.0 (the work I mentioned above) a bit more as I was at the MultilingualWeb-LT workshop the past three days and we discussed the use of XLIFF quite a bit.

My overall feel is that XLIFF is seen as an important medium in various scenarios where the upcoming ITS 2.0, as well as other vocabularies, are going to be used. As such it is really part of a wide set of formats that are integrated together. It doesn't exist alone and I think we should accommodate that fact.

Using metaHolder to map non-XLIFF data is going to work only to some extent. One example: ITS 2.0 is looking at a data category that would store QA errors. Such information is just not easily mapped to a simple key/value list, its better handled with elements. And the only way to have having extension elements is through namespaces.

There are other examples like that, and as a general concern, the metaHolder cannot handle all types of extensions that different companies/groups will use.

I would argue that the case for a future-ready 2.0 is stronger than a very-safe-but-very-limited 2.0. We need to define a 2.0 that will be in full use 5-10 years from now. And namespaces are part of that picture.


To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org

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