[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]