[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] XLIFF and ITS mapping-ID value
The ref attribute is defined in the Spec as follows:
"points to a
span of source text within the same unit...",
so I took it as inline elements only (I think because most of the available examples use them) by mistake.
I will note this correction in the next version of artefacts as well, thanks alot!
I would like to use the opportunity to ask all members of the list to share validation cases they come across for further troubleshooting.
Regards,
Soroush.
From: Yves Savourel [ysavourel@enlaso.com]
Sent: 21 December 2015 13:59 To: Soroush.Saadatfar Cc: xliff@lists.oasis-open.org Subject: RE: [xliff] XLIFF and ITS mapping-ID value Thanks for testing Soroush.
Interesting first error: the Okapi checker doesn’t get that one.
There is an "m1" identifier inside that unit: on the segment rather than on an mrk. From the fragment identifier syntax there is no way to know if #m1 is a segment or an mrk or a pc, etc. so that makes the validation a bit difficult (at least the way Okapi stores the parsed info about IDs).
Just to be sure: Did we decided against using a shortcut to the segment for the Translation Candidate annotation? The specification does not say anything explicit about not being able to use <segment>.
I’ll come back for the other errors later.
-ys
From: Soroush.Saadatfar [mailto:Soroush.Saadatfar@ul.ie]
The validator raises three errors; 1- Missing element with id="m1" to which the <mtc:match ... ref="#m1"> element is pointing (not in scope of this conversation); 2 & 3- ID duplication for both <pc> in <mtc:match>.
Seems like a tricky case, but I think it would make sense to treat <source>/<target> pairs in translate candidates along with those in <segment> or <ignorable> within the same <unit>. As <source> and <target> are both core elements even inside a module, according to the Spec inline elements inside them must have unique ids. Therefore even if the TC decides otherwise the text of Spec then should be modified. Using the NVDL's logic of breaking XML document by namespaces, <source> and <target>, children of <mtc:match>, will remain in the context of <unit> after omission of "mtc:" namespace.
P.S. I assume my validator might need some editing for this case anyway, thanks!
Best, Soroush.
From: Yves Savourel [ysavourel@enlaso.com] Hi Soroush, all,
On a related topic of IDs in XLIFF.
Could you give me your opinion on the test file I posted here: https://lists.oasis-open.org/archives/xliff/201512/msg00011/test-file.xlf
The question is: Is it valid to have the same id="1" ID in the two <pc> elements present in that file. What is your validator results for that file?
Thanks, -yves
From: Soroush.Saadatfar [mailto:Soroush.Saadatfar@ul.ie]
Dear Felix, Yves, Thanks for your help, your notes will be applied.
Regards, Soroush.
From: Felix Sasaki [felix@sasakiatcf.com] HI Soroush and all,
There is no example because as the wiki says: „Note that the identifiers in XLIFF are not unique per document, so using the Id Value data category to specify IDs in an XLIFF document is largely useless“. So I would leave this as as, without an example about such contexts.
Best,
Felix
________________________________________ From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] on behalf of Yves Savourel [ysavourel@enlaso.com] Sent: 19 December 2015 12:38 To: XLIFF Main List Subject: RE: [xliff] XLIFF and ITS mapping- Elements within text
Hi Soroush,
More notes:
-- 1)
Several of the examples have "curly quotes" instead of normal ASCII double quotes to enclose attribute values. A side effect of editing in an email probably, but they need to be correct in the spec.
-- 2)
<unit id="u1"> <originalData> <data id="d1"><br/></data> </originalData>--> <segment> <source>This sentence has a breakpoint<ph id="ph1" dataRef="d1" type="fmt" subType="xlf:lb"/>inside. </source> </segment> </unit>
The example above has a dangling "-->" after </originalData>.
-- 3)
<unit id="u1"> <originalData> <data id="d1"><u></data> <data id="d2"></u></data> </originalData> <segment> <source>A paragraph where <sc id="sc1" dataRef="d1" type="fmt" subType="xlf:u"/>the formatted text takes more than one segment. </source> </segment> <segment> <source> The second sentence here.<ec dataRef="d2" startRef="sc1"/> </source> </segment> </unit>
In the example above, the <ec/> element seems to be missing the attributes type="fmt" and subType="xlf:u".
Now, the Okapi validator gives an error on this, but I don't see in the spec any constraint that says type and subType must have the same values in two corresponding <sc/> and <ec/>. That constraint exists only for canCopy, canDelete and canOverlap.
I don't see anywhere either that the processor should magically complement the undefined attributes in <ec/> by looking at the corresponding <sc/>. At the same time, obviously, it would be illogical to have different values.
Are we missing yet another "implicit" constraint?
Cheers, -yves
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]