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] 1.2 to 2.0 Gaps and Proposals

Hi Ryan, all,

> ... see my inline to your inline.
> Please let me know if there is anything I can do to help you document 
> and get this added to the specification.
>  Do you feel we need to have a roll call vote on these items in the next TC call?

(this is related to the proposed changes in the match module) see below).

Personally I think it's best to work by consensus first, and only go to ballot when there is no consensus.
This TC is very ballot-driven so you should do whatever make sense in your opinion.

As for moving things forward: 

- type probably needs a revised list

- subType and ref probably need to be defined as they would appear in the specification.

So people can see it and provide feedback if they want.
If there is no feedback, one can assume there is no dissent and update the specification.

I'm afraid I have not much time to do specification update currently, but Bryan, Tom or David may.

cheers, (and sorry for being slow to answer emails)

-----Original Message-----
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Yves Savourel
Sent: Wednesday, November 28, 2012 7:48 PM
To: Ryan King; xliff@lists.oasis-open.org
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals

Hi Ryan, all,

Sorry for the delay: I'm just swamped and can't find the time to read emails anymore.

> 1. Be able to specify optional custom values for match type in 
> <mtc:matches>

I suppose some mechanism similar to the subType we're using in inline codes and other places could allow for custom values while making sure a top-level category is also declared.

Since we are discussing values for match type: I'm still not convinced that the latest list makes sense:

am - Assembled Match
ebm - Example-based Machine Translation
idm - ID-based Match
ice - In-Context Exact Match
mt - Machine Translation
tm - Translation Memory Match

- 'Example-based Machine Translation' should not be there IMO: it's just MT, what type of MT is not relevant (but could be a candidate for the subtype)
- 'In-Context Exact Match' IMO should be 'in-context' only: the fact that's an exact one is captured in the similarity (and it could be an in-context fuzzy too).

[ryanki] I think this makes sense. For example, there's no reason each of these couldn't be valid (note ic instead of ice):
<match id=”1” similarity=”100.0” type=”ic/xlf:exact”> <match id=”1” similarity=”100.0” type=”mt/xlf:exact”> <match id=”1” similarity=”100.0” type=”tm/xlf:exact”> <match id=”1” similarity=”75.0” type=”ic/xlf:fuzzy”>
<match id=”1” similarity=”75.0” type=”mt/xlf:fuzzy”>	
<match id=”1” similarity=”75.0” type=”tm/xlf:fuzzy”>

> 2. Support Reference Language in <mtc:matches> • Allow zero, one or 
> more <mtc:matches> at each extension point, because you might have 
> both recycling and reference language data.

I assume you mean: allow more than one <mtc:matches> where we currently allow one? Not in *all* extensions point. right?

[ryanki] exactement :)

> • Add an optional attribute reference=”yes|no” with no as default. 
> Additionally, PR for a “reference match” would be to allow an xml:lang 
> on the target different from the document and allow the <source> not 
> to be present as it would be redundant information with the core 
> <source>, e.g. Spanish reference for Quechua might look like this:

- reference='yes\no' and allowing a different language for xml:lang in those with reference='yes' seems ok to me.
- source not being present... I don't know. If we do that for those 'matches' why not for the normalmatches as well? If the source is the same. 
I think we mandated the source originally that's to simplify processing: testing for the presence of not of the source may be cumbersome for some processors (XSLT maybe?).

[ryanki] in principle, we could carry around the redundant <source> the only side effect really being bloat to the XLIFF (but metadata will do that anyway...) I suggested it this way simply because <alt-trans> the previous element used for reference language in 1.2, does not require <source>, so this was for parity.

We would need to update the definition of what a "match" is as well.

hope this helps,

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]