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 Bryan,

> I get disheartened when we start talking about eliminating
> the elegant choice of <pc> and make all cases use the 
> <sc>/<ec> pair, even in the majority use case where 
> inlines do not span segments.

The problem is that the elegance of <pc> is crumbling rapidly when you look at all the information the code can have. It looks fine and simple like this:

<pc id='1' type='bold'>text</pc>

But if you add the handling of the original data, the sub-flow pointers, the text equivalent, the simplified display, etc. the XML construction with a single opening tag when we need to specify data for both the start and end markers is making the graceful <pc> to quickly transform into an ugly duck.

> especially when the practice of escaping XML
> code was involved.

It is still involved.
At least if you want to store the original data.

Someday, soon, you'll have to explain how we can store the original code differently and still have the same mechanism for XML and non-XML original data.

By the way, I've posted some notes on your previous email here:


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