OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xliff] IDs - Optional attributes (E)


Hi David, all,

 

> While there is an optional id attribute on <ec> there

> is no id attribute on <em>, is there a reason for handling

> them differently? I guess it is because original codes can

> be orphaned in the sense that there is no corresponding

> start code anywhere in the scope, right?

> Whereas this is considered impossible for annotations?

 

Yes.

 

The general case for both <ec> and <em> is that these elements indicate closing of paired codes or annotations. So are associated with the same ID value as their corresponding opening part. The rational to use startRef was (I think) that it is a reference to an ID rather than the ID itself.

 

Only when <ec> is isolated (i.e. its opening part is not in the same <unit>) the element uses the id attribute. The rational in that case is that since it has no element to refer it shouldn’t use startRef.

 

For <em>, as you noted, the specification does not allow for annotations across units, so startRef can always be used and therefore the id attribute is not needed.

 

-yves

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]