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,

I like the idea of further simplification. The elements that Yves removed can be left away.

Segmentation information was optional in XLIFF 1.2 and should continue to be optional. The <part> element added by Yves should not be part of the basic tree. And, as I see it, any segmentation info should never be inside <source> or <target>, it should be at a higher level, preferably outside <trans-unit>.

Regards,
Rodolfo
--
Rodolfo M. Raya   <rmraya@maxprograms.com>
Maxprograms      http://www.maxprograms.com

> -----Original Message-----
> From: Yves Savourel [mailto:ysavourel@translate.com]
> Sent: Monday, August 23, 2010 12:15 AM
> To: xliff@lists.oasis-open.org
> Subject: RE: [xliff] Simplified XLIFF element tree
> 
> Hi,
> 
> For the core/minimal XLIFF I would go for an even simpler model than
> Rodolfo's:
> 
> -- I think segmentation is too important to not be part of the core structure
> of XLIFF, and the representation as extra info like it is the case in 1.2 (because
> of the need to be backward compatible with 1.1) is not adequate. It does not
> mean a file must always be segmented, just that representing a segmented
> content must be simple and the processing of segmented vs un-segmented
> content should be seamless. For simplicity I've represented this as <part> in
> the tree below, but it would be whatever structure we would end up with.
> 
> -- I wouldn't put all the alt-trans data in the core. It corresponds to specific
> features that are not core to represent extracted text.
> 
> -- I would select only essential parts for the core, and therefore not include
> the skeleton since it's not something essential for the extracted data (i.e.
> one can merge without using the XLIFF <skel> data, and ,skel> is really tool-
> specific anyway).
> 
> -- I would not reduce the XLIFF namespace to the core. Just declare as core a
> subset of element/attributes of the namespace.
> 
> 
> <xliff version1 >1
> |
> +--- <file original1 source-language1 datatype1 >+
>      |
>      +--- <body>1
>           |
>           +--- <group id1 resname? restype? >*
>           |    |
>           |    +--- [trans-unit]*
>           |
>           +--- <trans-unit id1 resname? restype? >*
>                |
>                +--- <source >1
>                |    |
>                |    +--- <part id? >+
>                |         |
>                |         +--- [inline markup]*
>                |
>                +--- <target >?
>                     |
>                     +--- <part id? >+
>                          |
>                          +--- [inline markup]*
> 
> 
> 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]