Thanks Yves and David! Ryan From: Dr. David Filip Sent: ?9/?4/?2015 2:02 PM To: Ryan King Cc: Yves Savourel ;
xliff@lists.oasis-open.org Subject: RE: Another validation question Ryan, I agree with Yves.. There was a discussion and there is indeed no reason to forbid target references from matches. The description was unfortunately not updated, it comes from the time we had only source similarity in the module. But later we added also quality and suitability so there is no longer a reason to restrict the references to source text. I also agree that source text is not text in source and would consider removing the word "source" from the definition in 2.1 an editorial clarification. Cheers dF dF is AFK, so please bear with the typos and call me at +353860222158 if my answer seems insufficient.. On Sep 4, 2015 18:39, "Ryan King" <
ryanki@microsoft.com > wrote: Thanks, Yves. +David and the rest of the discussion list. Ryan From: Yves Savourel [mailto:
ysavourel@enlaso.com ] Sent: Friday, September 4, 2015 3:53 AM To: Ryan King <
ryanki@microsoft.com > Subject: RE: Another validation question You are right: the definition seems to not allow this. The fact that there is a comment saying explicitly it is allowed make me think some discussion took place and it was decided it was fine. Which kind of make sense: why would we want to not allow pointing to a target reference? David may have more thought on this. If this is allowed we should remove “source” in the definition, if it’s not allowed we should be clearer in the definition, because “source text” is not quite the same as “text in <source>”. -ys From: Ryan King [ mailto:
ryanki@microsoft.com ] Sent: Friday, September 4, 2015 12:53 AM To: Yves Savourel <
ysavourel@enlaso.com > Subject: Another validation question Hi Yves, another question for you. The part in question is highlighted below. <?xml version="1.0"?> <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr" xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0"> <file id="f1"> <unit id="1"> <mtc:matches xmlns:xlf="urn:oasis:names:tc:xliff:document:2.0"> <mtc:match id="1" ref="#m1"> <metadata xmlns="urn:oasis:names:tc:xliff:metadata:2.0" > <metaGroup> <meta type="mytype">data</meta> </metaGroup> </metadata> <xlf:originalData> <xlf:data id="d1">[code]</xlf:data> </xlf:originalData> <xlf:source><xlf:ph id='1' dataRef='d1'/>Text</xlf:source> <xlf:target><xlf:ph id='1' dataRef='d1'/>Texte</xlf:target> <my:element xmlns:my="myNs">data</my:element> </mtc:match> <mtc:match id="2" ref ="#t=m2 "> <!-- Refers to a target (unlikely but allowed) --> <xlf:source>Text2</xlf:source> <xlf:target>Texte2</xlf:target> </mtc:match> </mtc:matches> <segment> <source><mrk id="m1" type="mtc:match">Text</mrk></source> <target><mrk id="m2" type="some:annotation">Texte2</mrk></target> </segment> </unit> </file> </xliff> According to the spec this seems to be invalid, assuming source means Source (not Target) which is how I read it. Reference - points to a span of source text within the same unit, to which the translation candidate is relevant. Value description: IRI Default value: undefined Used in: <match> . They seem to conflict. Just wondering, am I missing a nuance here? Thanks, Ryan