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] RE: [xliff-inline] Representing information for the starting/ending/standalone parts

Hi Fredrik, all,

> ...If my initial understanding is correct

It is.

> it is my position that it makes more sense to 
> only have the <sc>+<ec> pair of tags for paired 
> codes. The rational for that is that they can 
> represent all paired codes regardless of the 
> source format and the segmentation of the source.


> ...The issue here is that, as the initial mail 
> in the thread indicate, <pc> can not exist alone.
> It must have other elements to support it 
> for some documents.


Bryan has the good luck (or bad one, I'm not sure) to live in the beautiful indigo world of XML documents that he controls. And he is paying the price of consorting with unsavory people who have to work with orange, green, red and even yellow documents, and are bent on having a solution that work with all the colors of the rainbow.

Kidding apart, the question is whether we want to allow one more XML-friendly way to represent some cases, even if it means more complexity for the XLIFF processors.

The thing is, if you read the XML file into your own internal representation this matter probably little as both notation are mapped to a unique one. But it matters more if you work directly with the XLIFF document because you have to make provision for both representation all the time.

(going back to helping cooking pies)

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