[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] XLIFF and ITS mapping-ID value
Dear Felix, Yves,
Thanks for your help, your notes will be applied.
Regards,
Soroush.
From: Felix Sasaki [felix@sasakiatcf.com]
Sent: 20 December 2015 20:41 To: Soroush.Saadatfar Cc: xliff@lists.oasis-open.org Subject: Re: [xliff] XLIFF and ITS mapping-ID value 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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]