Re: [xliff-comment] XLIFF 2.1 csprd02: Multiple comments on CTR module

[David Filip <david.filip@adaptcentre.ie>]

Hello Chase,

great thanks for taking the time and reviewing the csprd02 of XLIFF Vesrion 2.1

On behalf of the XLIFF TC, I created this issue

https://issues.oasis-open.org/browse/XLIFF-44

from your comment.

Please follow the resolution/disposal of your comment on the above address

In case you want to follow up on the comment resolution please continue this conversation that is referenced from the JIRA issue under the following markmail link

http://markmail.org/thread/pktkfcp3ipeyk7sf

The TC plans to resolve your comment in the TC meeting on 7th March 2017 and reflect the resulting changes in a new working draft by 15th March, 2017.

Cheers and thanks again

dF

Dr. David Filip

===========

OASIS XLIFF OMOS TC Chair

OASIS XLIFF TC Secretary, Editor, Liaison Officer

Spokes Research Fellow

ADAPT Centre

KDEG, Trinity College Dublin

Mobile: +420-777-218-122

On Fri, Feb 24, 2017 at 6:40 PM, Chase Tingley <chase@spartansoftwareinc.com> wrote:

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 governs the type of and possible content allowed in the grandchildren of specific <revisions> elements:
  
• If and only if the REQUIRED appliesTo attribute value is unit, the <revisions> element MUST have exactly one <unitItem> grandchild element.
• If and only if the REQUIRED appliesTo attribute value is segment, the <revisions> element MUST have exactly one <segmentItem> grandchild element.
• If and only if the REQUIRED appliesTo attribute value is source or target, the <revisions> element MUST have exactly one <contentItem> grandchild element.

In section 5.6.6.8, it is noted that:

• Modifiers MUST NOT use the item element to track changes of <unit>, <source>, or <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> +
    |
    +---<xlf:originaldata> ?
    |
    +---<ctr:item> *
    |
    +---Exactly one of <contentItem> OR <segmentItem> OR <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.