Re: [xliff] Problem with the note proposal

[Tony Jewtushenko <tony.jewtushenko@oracle.com>]

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.

Regards,
Tony




John Reid wrote:
> 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." 

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