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


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]