[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (XLIFF-4) Simplify Change Tracking Data Model
[ https://issues.oasis-open.org/browse/XLIFF-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=64674#comment-64674 ] Yves Savourel commented on XLIFF-4: ----------------------------------- > Under <revisions> you must create a new <revision> for each version, > so no need to move the data back onto the "items" (we had them there > in an earlier version and you suggested to move them up to <revision> > which I think makes sense). My mistake: We can't have overlap since we can have only one content/unit item under a single revision. My problem is on the implementation: Having the originalData map not in the item is making re-using objects or common interfaces quite complicated. I'll see if I can implement things differently (different types of revision objects in addition to different types of item objects). This said, the spec says for <revision>: - One or more <item> or <contentItem> or <unitItem> elements it's really: - either: - one <contentItem> and zero or more <item> - one <unitItem> and zero or more <item> - one or more <item> Hopefully the XSD can validate that. > Simplify Change Tracking Data Model > ----------------------------------- > > Key: XLIFF-4 > URL: https://issues.oasis-open.org/browse/XLIFF-4 > Project: OASIS XML Localisation Interchange File Format (XLIFF) TC > Issue Type: Improvement > Components: Change Tracking Module > Affects Versions: 2.1_csprd01 > Environment: https://lists.oasis-open.org/archives/xliff-comment/201610/msg00015.html > Reporter: Yves Savourel > Assignee: David Filip > Labels: request_tc_discussion > Fix For: 2.1_csprd02 > > > It seems to me the new model for change tracking is too complicated to be implemented without a) a lot of efforts and b) mistakes. > Having different types of content in <item> and <simpleItem> based on the property attribute and the grand-parent element's > appliesTo attribute is not going to make things easy. > I would propose to simplify things: > If the change is on the content of a <source> or <target>: > -> Use a <contentItem> element that contains text and zero or more inline codes (same as a source or target content) > If the change is on the content of a <unit> (e.g. segmentation): > -> Use a <unitItem> element that contains one or more <segment> and zero or more <ignorable> (same as in <unit>) > In all other cases: > -> Use an <item> element that has plain text > - Neither <contentItem> nor <unitItem> would have a property attribute, or if they do it would be default and fixed to 'content'. > - The property in <item> could be set to 'content' only if the revisions' appliesTo is 'note' > As for dealing with orphan <sm/> and <em> in <contentItem>: I would propose to make them <mrk> with a new CTR attribute > ctr:added='sm|em' to indicate that the original was either a <em/> (added='em')or a <sm/> (added='sm'). -- 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]