RE: [xliff] XLIFF and ITS mapping- Elements within text

[Yves Savourel <ysavourel@enlaso.com>]

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">&lt;br/&gt;</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">&lt;u&gt;</data>
      <data id="d2">&lt;/u&gt;</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