[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xliff] Problem with the note proposal
Tony, My comments follow: > I have heard back from Karl, and the definition of "substantive" is > subjective, and totally up to the individual TC to determine if changes > to spec warrant conducting another peer review period. From our > previous discussions, I infer that the TC would consider these changes > to be non-substantive, and therefore we would chose against having > another peer review. Good. I agree. This is not substantive unless we change current meaning and usage. > Good points about the <note> annotates attrib. However, regarding your > reading of the <note> spec, John, the present 1.1 spec is totally > ambiguous about what <note> refers to and does not specify that note > refers to <source>. The present definition says: > > "The content of <note> may be instructions from developers about how > to handle the <source>, comments from the translator about the > translation, or any comment from anyone involved in processing the > XLIFF file.". > > Please look carefully at the word "may" - it indicates that the content > of note can refer to anything at all, including "comments from the > translator about the translation (e.g., target)". So the spec prose > regarding "<source>" is simply an example of possible usage and not > canonical. I was not clear. For the <trans-unit>, not the <note>, the 1.1 spec says, "All child elements of <trans-unit> pertain to their sibling <source> element." Thus, a strict reading of this says any <note> in a <trans-unit> pertains to the <source>. It would be the <trans-unit> that would need changing. Maybe the ambiguity of <note> could be addressed another time. > In any case, it looks like we may need to abort this ballot item, but > I can't do it until we reconvene the meeting next week. ... I don't believe we can abort a ballot item. If it doesn't pass, we can consider alternatives as you and I have discussed. It might be that others think my interpretation is too strict and that no change is required to the <trans-unit>. A simple change to the <trans-unit> statement, above, such as, "All child elements of <trans-unit> pertain to their sibling <source> element, unless noted or logically related otherwise."
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]