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

["Schnabel, Bryan S" <bryan.s.schnabel@tektronix.com>]

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


Ah Yves my friend if that were only true . . . I would write beautiful poems about the blissfulness of naivety. I would invite my friends to come visit this my wonderful world to smell flowers and chase butterflies.

Alas, my world has many colors too. When I have to process files from our highly customized Enovia PLM, the colors of the jsp, tcl, and mql (a proprietary sql-like syntax) on a good day are those of tutty fruity ice cream, on a bad day, all blend into gray. And when I process Drupal it is a mix of XHTML, php, and murky PO strings - the colors are bright and primary, until you factor in the PO. And then there are the days I must process our instrument software (UI, firmware, etc.), yes our customers want to operate instruments in their own language, sometimes Windows, sometimes not, sometimes our own proprietary mix of who knows what – I see the entire spectrum. And when I process the many flavors of RTF from many vintages, many regions, and many OS's, I cannot find color at all. And I still have to process Interleaf files (they call it Interleaf ASCII, unix and Windows), mostly light brown with tinges of red I think . . .


________________________________________
From: xliff@lists.oasis-open.org [xliff@lists.oasis-open.org] On Behalf Of Yves Savourel [ysavourel@enlaso.com]
Sent: Sunday, October 09, 2011 4:01 PM
To: xliff-inline@lists.oasis-open.org
Cc: xliff@lists.oasis-open.org
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.

Exactly.


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

Yes.

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.

Cheers,
-yves
(going back to helping cooking pies)



---------------------------------------------------------------------
To unsubscribe, e-mail: xliff-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xliff-help@lists.oasis-open.org