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

> I agree with your goals. There should be one representation for
> segmented content, which could very well be a traditional <trans-unit>
> with a <source>/<target> pair.
> The 2nd goal can be achieved by keeping the optional unsegmented text
> separate from the segmented version. In other words, separate from the
> traditional <trans-unit> that could be used for the first goal.

One concern I have is that we replicate what we have with <seg-source> - where we have two different representations of the source content, one with segment markers, and one without. I'm not sure what the intentions of this was, but I'm guessing it has to do with the ideal of keeping the content of <source> immutable - which is a good goal. 

I am, however, wondering if this immutability-goal can be accomplished by other means, for instance by having a specific set of inline-codes for content-markup (which is basically <mrk> as it is implemented today), and describing some processing expectations for working with the original extracted content. In that way, annotating segments can be done directly within <source>. This is probably something that will become clearer as we continue the work within the inline content sub-committee. 


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