David, I agree with your proposal below. Do we want to consider @approved as well?
Ryan
From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org]
On Behalf Of Dr. David Filip
Sent: Wednesday, August 7, 2013 6:36 AM
To: xliff@lists.oasis-open.org; Yves Savourel; Estreen, Fredrik
Subject: [xliff] Re: Proposed changes to translate attribute (and related) in response to csprd01 comment 009 (translate clarification), related to 038 (resegmentation PRs)
Hi all, Fredrik, Yves, Ryan..
There was no discussion on this one for the last month, so I suppose that there is no dissent with the fully recursive solution as outlined below.
I will also review other similar flags that should be recursively flipped through the structural levels and wil limplement fully recursive imnheritance for them unless someone objects within this week.
The list of affected attributes IMHO should be the following:
resegmentation flag - Introduced in response to comment 038 - I am defining @canResegment across all structural levels down to <segment>.
Please let me know if you think that other core or module attributes should have fully recursive inheritance like the above ones.
Thanks for your attention and best regards
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
On Fri, Jul 5, 2013 at 2:11 PM, Dr. David Filip <David.Filip@ul.ie> wrote:
I believe that the translate attribute (flag) should be allowed on all structural levels above segment.
Currently it is only allowed on <unit>, <segment>, and <markers>.
I believe that not having it on <group> and <file> as well is an omission.
Yves also commented that we do not specify scope, which is another bad omission.
So I propose that the translate values are fully recursively inherited by all structural elements and markers.
The default applies for all the levels above the highest explicitly set (all if none set). All lower levels inherit their default from the closest level above.
IMHO the above is clear and not contentious, one point to discuss is whether we want to allow the segment element to carry the attribute.
Since the attribute is specified in core, the PRs could be set for re-segmentation, I am just not sure if it is worth the hassle.
We could simply disallow the attribute on segment and say that translate values set on unit have to be overriden with markers if need be. This would resonate with the general approach to re-segmenting, i.e. make the segment as simple as
possible to make the re-segmentation PR as simple as possible.
Please let me know your thoughts on this within next week
Thanks for your attention
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland