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

<group>
<extr-text>
<trans-unit>

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

Rgds
dF



David Filip
Director, Research
==============================
www.moraviaworldwide.com
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.

Cheers,
-ys



---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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