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

[Yves Savourel <ysavourel@enlaso.com>]

Thanks for the reminder on this Soroush.
I don't have any additional comment and I'm looking forward to other input.

-ys

-----Original Message-----
From: Soroush.Saadatfar [mailto:Soroush.Saadatfar@ul.ie] 
Sent: Monday, April 25, 2016 11:13 AM
To: Yves Savourel <ysavourel@enlaso.com>
Cc: XLIFF Main List <xliff@lists.oasis-open.org>
Subject: Re: [xliff] XLIFF and ITS mapping- Elements within text

Dear Yves, all,
I just found this “unsolved thread” while reviewing the spec text for ITS module in XLIFF 2.1 and I think it’s worth finalizing this question.

> -- 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?

My validator does not raise any error for it and it seems, at least to me, that current attributes of dataRef and startRef provide sufficient information.
On the other hand, as Yves mentioned, it is not explicitly mentioned in the spec.
Please share your thoughts.

Best,
Soroush.







> 
> On Dec 19, 2015, at 12:38 PM, Yves Savourel <ysavourel@enlaso.com> wrote:
> 
> 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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
>