RE: [xliff] Metadata extensibility ballot

[Helena S Chapman <hchapman@us.ibm.com>]

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.

Cheers,
-yves



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