[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (XLIFF-44) CTR Module feature creep?
[ https://issues.oasis-open.org/browse/XLIFF-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Filip updated XLIFF-44: ----------------------------- Reporter: Chase Tingley (was: David Filip) > CTR Module feature creep? > ------------------------- > > Key: XLIFF-44 > URL: https://issues.oasis-open.org/browse/XLIFF-44 > Project: OASIS XML Localisation Interchange File Format (XLIFF) TC > Issue Type: Improvement > Components: Change Tracking Module > Affects Versions: 2.1_csprd02 > Environment: http://markmail.org/thread/pktkfcp3ipeyk7sf > Reporter: Chase Tingley > Assignee: David Filip > Priority: Blocker > Labels: AdoptionBlocker, request_tc_discussion, work_required > Fix For: 2.1_csprd02 > > > I'm combining several comments into a single message. The first one is a > general concern, and the subsequent ones are specific examples (which may > also illustrate that concern, in their own ways). > *1. General concern about complexity* > I am concerned that this module is suffering from feature creep, and that > it will hinder the effective implementation of the module. The module is > now attempting to solve several separate problems at once: > - Tracking changes to note content > - Tracking changes to attribute values on arbitrary (I think?) elements > - Tracking changes to content at the source, target, segment, or > unit-level > The overloading that makes this possible makes the schema difficult to > understand and, I fear, unlikely to be supported fully. As the content > tracking is a substantially different model, it could even be argued that > it should be split off to a separate module. > *2. Incorrect example in section 5.6.8* > The first two <ctr:revisions> elements in the example in 5.6.8 have > appliesTo values of "source" and "target" respectively. > By my reading of section 5.6.6.3, this means that these revisions should > use <contentItem> to track the full source and target contents: > If and only if the REQUIRED appliesTo attribute value is source or target, > the <revisions> element MUST have exactly one <contentItem> grandchild > element. > In the example, these revisions use <item> for the source and target > content, which looks incorrect. > *3. Questions regarding element hierarchy within <revision>* > In describing the contents of <revisions> in 5.6.6.3, it says: > - The value of the REQUIRED attribute appliesTo > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#ctr_appliesTo> > governs > the type of and possible content allowed in the grandchildren of specific > <revisions> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#revisions> > elements: > - If and only if the REQUIRED appliesTo > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#ctr_appliesTo> > attribute > value is unit, the <revisions> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#revisions> > element > MUST have exactly one <unitItem> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#unitItem> > grandchild > element. > - If and only if the REQUIRED appliesTo > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#ctr_appliesTo> > attribute > value is segment, the <revisions> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#revisions> > element > MUST have exactly one <segmentItem> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#segmentItem> > grandchild > element. > - If and only if the REQUIRED appliesTo > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#ctr_appliesTo> > attribute > value is source or target, the <revisions> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#revisions> > element > MUST have exactly one <contentItem> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#contentItem> > grandchild > element. > In section 5.6.6.8, it is noted that: > - *Modifiers* MUST NOT use the item > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#item> > element > to track changes of <unit> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#unit> > , <source> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#source>, > or <target> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#target> > content. > Based on these two sections, I infer that it is not possible to have a > <item> in the same <revision> as any of unitItem/segmentItem/contentItem: > - If revisions/@appliesTo="unit", then the <revision> must contain > <unitItem>; <item> is not allowed to track changes on <unit>, so it can't > be used > - If revisions/@appliesTo="segment", then the <revision> must contain > <segmentItem>; <item> is not allowed to track changes on <source> or > <target>, so it can't be used > - If revisions/@appliesTo="source" or "target", then the <revision> must > contain <contentItem>; <item> is not allowed to track changes on <source> > or <target>, so it can't be used > So it seems like there is no case in which <item> can be present within the > same <revision> as one of these specialized units. > However, the element diagram in section 5.6.6.1, it appears that this is > allowed: > +---<revision> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#revision> > + > | > +---<xlf:originaldata> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#originaldata> > ? > | > +---<ctr:item> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#item> > * > | > +---Exactly one of <contentItem> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#contentItem> > OR <segmentItem> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#segmentItem> > OR <unitItem> > <http://docs.oasis-open.org/xliff/xliff-core/v2.1/csprd02/xliff-core-v2.1-csprd02.html#unitItem>) > In what circumstance would this be possible? And if it is not > possible, should the diagram be changed? > *4. Use of <xlf:originaldata> in revisions* > It is currently legal to include <xlf:originaldata> inside a > <revision> element even if the revision only contains <item> data. > This is (I think) nonsensical. > Wouldn't <xlf:originaldata> only be useful if one of <contentItem>, > <segmentItem>, or <unitItem> were present? > *5. Use of "property" attribute element in <contentItem>, <unitItem>, > or <segmentItem>* > In all these elements, "property" is required but has only one > possible value. This appears like it's being done either for symmetry > with <item> or for some sort of future-proofing, but I question > whether it is useful. -- 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]