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] Section 2.6.7 "Target Content Modification" - Split/Merge

Thank you very much Fredrik, Yves for your feedback.

I had to wait for the opinions of developers here regarding your feedback.

We agree with Yves's approach to have a single attribute (or two) to prevent re-segmentation by other tools.
We will wait for a few more feedback from Fredrik and others.


On 10/12/2012 13:06, Yves Savourel wrote:
Hi Jung, Fredrik, all,

The sentence in should be removed. Or reworded to 
say that the user agent may leave the segment without a target.

On Regarding the current rules on splitting and joining.
And I do not think you are alone in wanting to do so. This all 
comes down to the dynamic vs. static behavior of the <segment> 
and <ignorable> elements. 
I think having some kind of mechanism that indicates a unit should not be re-segmented would be perfectly acceptable. This type of requirement exists for example in XLIFF:doc from Interoperability Now. this notion is also listed in our wiki (See the section "Segment modification" in https://wiki.oasis-open.org/xliff/XLIFF2.0/Feature/Segmentation).
We had no discussion on this until now, but that doesn't mean we should not.

An alternative to the attributes on segment that I feel is 
cleaner is to leverage the static structure property of <unit>.
If you have non sub dividable pieces that you want to preserve 
they should be put in a <unit> each and in the <unit> you put 
a single <segment>.
I would prefer to use some unit-level attribute than re-purpose the group/unit. Hinting that putting the segment representation may be done that way would somewhat go against the idea of having only one way to do one thing.

I'd rather have a clear attribute that indicate what re-segmentation operation can be done on a unit.

An extra note for the Inline-SC members: This discussion is related to text in a sub-section that lives in the "Inline Content" section, but it concerns more the general structure than the inline markup. I think any potential change here would not affect the overall inline markup proposals. So I think we can proceed in the SC with moving our proposals to the TC.


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


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