[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: XLIFF 2.1 csprd02: Multiple comments on CTR module
If and only if the REQUIRED appliesTo attribute value is source or target, the <revisions> element MUST have exactly one <contentItem> grandchild element.
- 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 isunit
, the<revisions>
element MUST have exactly one<unitItem>
grandchild element.- If and only if the REQUIRED
appliesTo
attribute value issegment
, the<revisions>
element MUST have exactly one<segmentItem>
grandchild element.- If and only if the REQUIRED
appliesTo
attribute value issource
ortarget
, the<revisions>
element MUST have exactly one<contentItem>
grandchild element.
+---<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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]