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: Re: [xliff] Problem with the note proposal

Hi John:

The change in trans-unit that you suggest: 
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." 
doesn't address the problem that the values for note's annotates attrib would be invalid outside of <trans-unit>.    For example, <note annotates="source">
is perfectly valid in <header>,  but what meaning would it have?  It seems to me that outside of <trans-unit>,  annotates could only have the value "general",  since  "source" and "target" would be ambiguous.  The only way to fix that is to only permit annotates = its siblings name.

I can abort (by deleting) the ballot,  but I won't.  We'll go through the balloting process to completion.  By the way,  it is possible to change your vote anytime up until the ballot closes,  in case anyone has second thoughts.

Note that if the measure passes,  those strongly against it have the right to author a minority report when we vote on the committee spec.  The minority report then becomes part of the specification.


John Reid wrote:

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
to spec warrant conducting another peer review period.  From our 
previous discussions,  I infer that the TC would consider these
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
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
    to handle the <source>, comments from the translator about the
    translation, or any comment from anyone involved in processing
    XLIFF file.".

Please look carefully at the word "may"  - it indicates that the
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 

I was not clear. For the <trans-unit>, not the <note>,  the 1.1 spec

"All child elements of <trans-unit> pertain to their sibling <source>

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

In any case,  it looks like we may need to abort this ballot item, 
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." 


Tony Jewtushenko					mailto:tony.jewtushenko@oracle.com
Principal Product Manager				direct tel: +353.1.8039080
ST Tools Technology Team
Oracle Corporation, Ireland

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]