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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff-inline message

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


Subject: RE: [xliff-inline] Representing information for the starting/ending/standalone parts


Hi Christian,

> ...I guess I lost track of the argument why we 
> need two representations (sc/ec and pc). 
> Could someone please remind me?

It's a good question. Original codes like HTML <b> maybe start in one segment and end in another. So being able to represent the start code and the end code as standalone XLIFF element is necessary because the segments are represented as elements and one cannot have something like this <seg>..<pc>..</seg><seg>..</pc>..</seg>.

We could represent all span-like codes with <sc>/<ec>.

But we do have currently a requirement (#17): "Should preserve span-like structures" (http://wiki.oasis-open.org/xliff/OneContentModel/Requirements#Shouldpreservespan-likestructures) and the <pc> representation is the proposed solution for that.

Having <pc> does bring a set of extra attributes because we have to store both starting and ending information in the same element.

One of the questions we have not discussed yet is how stringent we want the specification to be on the use of <sc>/<ec> vs. <pc>.

On a side note: We could actually even go further in simplicity and have only a unique <ph> element with an optional attribute that would indicate wither it represents a start, end or placeholder code. Overall it wouldn't change the information XLIFF would carry. I think having distinct elements allows a little more control of the validation.

Cheers,
-yves




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