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: [OASIS Issue Tracker] (XLIFF-32) CTR Usability


    [ https://issues.oasis-open.org/browse/XLIFF-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65754#comment-65754 ] 

David Filip commented on XLIFF-32:
----------------------------------

This is now committed to SVN AND printed. Assigning to Soroush, as he needs to change the Advanced Validation to reflect removal of CTR as a module

> CTR Usability
> -------------
>
>                 Key: XLIFF-32
>                 URL: https://issues.oasis-open.org/browse/XLIFF-32
>             Project: OASIS XML Localisation Interchange File Format (XLIFF) TC
>          Issue Type: New Feature
>          Components: Change Tracking Module
>    Affects Versions: 2.1_csprd02
>         Environment: http://markmail.org/thread/udmpeio52di5p44s
>            Reporter: Yves Savourel
>            Assignee: Chase Tingley
>            Priority: Blocker
>              Labels: AdoptionBlocker, Approved, work_required
>             Fix For: 2.1_csprd03
>
>
> https://lists.oasis-open.org/archives/xliff/201612/msg00015.html
> I'm still quite a bit uncertain about the CTR module.
> We have almost no example on how it would be used and no coded implementation at all.
> I've tried to manually go through the different steps of changes a unit may go through in the attached example.
> (Note that to put everything in a single file each unit is the next version of the previous one, not separate units). I've tried to
> make sure there were inline codes, segmentation (but no orphan inline-codes I'm afraid)
> The changes recorded are still very basic.
> (And BTW I have not validated it).
> I assumed the way the module is supposed to be used is as follow:
> When a change is made, the version before the change is save as a CTR entry and final result of the change set is the normal content
> of the unit.
> Is it the expected way to do it?
> This led me to several questions:
> - How do we represent entries that do not exist yet?
> For example if you add a note and there is no notes in the unit: what do we record?
> - I'm not sure what the version attribute can be used to do. Is it to link together all entries corresponding to a set of changes
> done during the same session? (Within and across units?)
> - What do we do when a change is linked to something we don't track? For example an <mrk> is added in the source when adding a
> translation candidate. We could track the new <mrk>, but not the match it corresponds to, so how could we restore a previous
> version?
> It seems to me that we have design the CTR module backward: Looking at the representation first, instead of trying to implement
> change tracking (i.e. really coding a tool doing it) and coming up with a representation based on the needs.
> https://lists.oasis-open.org/archives/xliff/201612/msg00028.html
> -- Out of context issues
> As we store content in unitItem and contentItem, there is the issue of context that crops up: Some information like xml:space or
> translate go across segment, or even across units, and may not have a physical representation in the XLIFF snippet we store.
> For example taking a segment content out of the context of its surrounding other segments may hide the fact that it is not
> translatable because there are some <mrk id='1' translate='no'> in the previous segment.
> That information cannot be stored in <contentItem>. It may be OK, but that may also have side effect when restoring the data in a
> different context.
> Another illustration of context issue: <mrk type='comment' ref="#n1"> is a comment referring to a note. If we store this in, for
> example, an <itemContent> because the translation has changed, there is no guaranty that the note n1 will stay there, or even point
> that n1 corresponds to the same note after some other changes. So we can end up with invalid references.
> Overall, it seems the content of a <revision> is bound to break the normal content constraint at some points because a) It is stored
> in a different context and b) It is not stored with all its 'dependencies'.
> -- Validation troubles:
> We say we do not want orphan <mrk>, but there are other validation issues with the stored content.
> For example the id value of a segment may exists twice: in the true content and in one (or more CTR entries). If they do have the
> same values, they break the constraint of http://docs.oasis-open.org/xliff/xliff-core/v2.0/xliff-core-v2.0.html#id where the
> specification says that when id is used with segment "...the value MUST be unique among all of the above (segment, etc.) within the
> enclosing <unit> element."
> I'm running into a lot of problems when trying to read back contentItem and unitItem.
> I think most of those questions are still un-answered and relate to the issue
> https://issues.oasis-open.org/browse/XLIFF-22: how the
> CTR module really works?



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


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