RE: Issue-55: XLIFF mapping - Terminology and termInfoPointer

>> --- Can we put other ITS data categories in that same <mrk> too?
>> -> why not?
> I understand that the mrk is taken exclusively for term if 
> the mtype="term" and I think this is OK.
> Generally I am not opposed to using mrk for multiple functions. 
> But we should be using core repertoire for encoding ITS stuff 
> whenever possible to nurture general interoperability and not 
> enforce support for its specific constructs to make use of the 
> metadata. So for me being able to use a generic method is more 
> important than making mrk generally usable for encoding more its
> categories at the same time..

That's nice. But in the original document side we may have combinations of ITS data categories on the same element. We can split them into several <mrk>, but then again, the round-trip become complicated: we change the markup of the original content, with all the side effects I've mentioned already.

>> --- How do we express its;term='no'?
>> Is it even needed in XLIFF?
> I do not think it is needed. Term='no' can be either ignored on 
> extraction. Or if we insist on having it we can introduce mtype='x-its-Term-No' 
> or similar.
> This is similar to the translate solution, we chose mrk mtype="protected">...</mrk> 
> and the verbose <mrk mtype="x-its-Translate-Yes">...</mrk> for the opposite value.

I tend to agree. But that would mean XLIFF would have no way, in a round-trip, to "un-termify" a text that was defined as a term in the original. that's fine by me. But is it by all?

>> --- Do we want to have a <source>/<target>-level terminology info?
> I do not think that terminology on structural level is strong enough use case.
>> If no: then what do we do with something like <html:p its-term='yes'>word</html:p>?
> I do not think that paragraphs should be systematically considered as being 
> possible terms. If a paragraphs happens to consist of a single term, I think that 
> it is an exception, and even the authors should be encouraged to use an 
> embedded span for encoding this rather than say that the whole paragraph is a term.
> I believe that terminology generally and typically appears 'inline'
> and that we should be concentrating on this is as the main success scenario.

Fine by me. that solves a lot of issues.
But then we need to convey this in the BP note going along with the mapping.
Regardless of what we decide, there will be people who will be using term on structural elements. So it has to be very clear to them that the XLIFF mapping does not allow this.

Shouldn't we start an actual Note document rather than a simple wiki table for the mapping?


Received on Wednesday, 20 February 2013 12:38:41 UTC