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] Simplified XLIFF element tree

Hi all,
It seems that most of us are more or less comfortable with having an extra layer for unsegmented, just extracted.. Same as Yves I believe that the unsegmented should be obligatory. But people like Andrzej and Rodolfo may have valid reasons for doing it the other way round..[although I agree with Asgeir and Yves that Andrzej can have more robust relationship with xml:tm in the new proposed setting]

I believe that we do not get any further without some solid use case analysis
IMHO we need to figure out rather combinatorically  what is the hierarchical relationship of


Which of them belong to XLIFF 2.0 core and how each of the possible combinations captures various content lifecycle scenarios

I suggest to not continue this thread until the f-t-f and Symposium in Limerick.
I believe that supporting use cases should be presented there..


David Filip
Director, Research
Phone:    + 420-545-552-203
Fax:         + 420-545-552-233
Mobile:   + 420-731-492244
E-mail:     davidf@moraviaworldwide.com

Děkujeme, že zvažujete dopad tisku emailů na životní prostředí./ Thank you for considering the environmental impact of printing emails.

-----Original Message-----
From: Yves Savourel [mailto:ysavourel@translate.com] 
Sent: Tuesday, August 24, 2010 2:23 PM
To: 'xliff'
Subject: RE: [xliff] Simplified XLIFF element tree

Hi Rodolfo, all,

>> It seems it would be simpler to have one element for each extracted 
>> unit, and the un/segmented information inside that element: Any type
>> of parser can access all of it at once, no need for linking or other
>> extra mechanism; finding/fixing/editing files is easier; etc.
> Please keep unsegmented information separate from translatable segments. 
> Like Andrzej, I don't plan to put unsegmented text in my XLIFF files.
> A common parent for unsegmented/segmented would be annoying unless it 
> is optional.
> Unsegmented text should be optional, as it is not needed for translating
> a segmented XLIFF. Unsegmented text should not be in the core XLIFF 
> module, it should live in a separate optional namespace.

Having the un-segmented text not part of the core and living in a separate optional namespace is a strange idea.

The first goal of XLIFF is to represent extracted text, not segmented extracted text.
The representation of the segmentation is what should be optional.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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