RE: [xliff] XLIFF 2.0 Core

[Yves Savourel <ysavourel@translate.com>]

> We could have matches at <unit> and at <segment> level 
> but I'm not sure it is necessary. If you have a match 
> at <unit> level generated from a paragraph, it can be 
> segmented with the same mechanism you use to split 
> the extracted text into <segments>.

There are cases when this may not always be a solution:

- The component that adds the matches may not have a way to segment.
 
- Breaking down the unit match into segment matches would require to align the split entries, which is more involved than just segmenting.

- Having both may be a deliberate choice from the provider of the XLIFF file.



> It's OK for me to move <match> and <note> to a different
> namespace, as long as it is an official namespace defined
> by the XLIFF TC. 

We touched on this at the last teleconference, as Bryan noted.
We need to define exactly how the core and the different modules are setup. I'm not sure the modules necessarily need to be in different namespaces. If they are, it certainly needs to be XLIFF-defined ones, no question there.

There are probably some advantages to have a different namespace for each module (e.g. for validating a document against a specific sub-set of XLIFF) but it also makes adding various XLIFF elements/attributes a lot more complex for the tools.

-ys