OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[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]