[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]