[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (XLIFF-44) CTR Module feature creep?
David Filip created XLIFF-44:
--------------------------------
Summary: 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: Bug
Components: Change Tracking Module
Affects Versions: 2.1_csprd02
Environment: http://markmail.org/thread/pktkfcp3ipeyk7sf
Reporter: David Filip
Assignee: David Filip
Priority: Blocker
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]