[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:comment-tabpanel&focusedCommentId=65347#comment-65347 ]
David Filip commented on XLIFF-44:
----------------------------------
My first take on this:
*1. General concern about complexity*
To be deferred until TC discussion on March 7, 2017
*2. Incorrect example in section 5.6.8*
Yes, the example is wrong as it hasn't been adjusted for the current data model. NEEDS FIXED..
*3. Questions regarding element hierarchy within <revision>*
<item> will exist within the same <revision> with one of the more complex "*Items" when it is used to track an attribute of the tracked element as opposed to its content.
Therefore the tree is correct.
*4. Use of <xlf:originaldata> in revisions*
On xsd level you cannot disallow original data on revisions where the more complex "*Items" don't exist. They're optional in this data model to allow for original data in the more complex cases, even in the complex cases he data is not required.
We could impose such co-ocurrence Constraint though and enforce it with the Module schematron.
I think it's a good idea and we should pursue it..
*5. Use of "property" attribute element in <contentItem>, <unitItem>,
or <segmentItem>*
Yes, it is to stress the analogy/symmetry with <item>. I think it makes the complex data model better readable. From the logic of the data model there must be at most 1 element with the property set to "content". Therefore if there is a <contentItem>, <unitItem>, or <segmentItem> in a <revision>, no <item> can have property set to "content". I think it makes the rule more elegant ;-) It makes it clearer why there must be exactly one <unitItem> when tracking the content of <unit> and so on..
> 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: David Filip
> 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]