OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message


Subject: Re: [xliff] Problem with the note proposal


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 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.

Annotates="source" doesn't make sense for a note in the <header> so I agree with your suggestion to modify the proposal so that note always annotates its parent and that the values for "annotates" are any of its possible siblings.

Howeve, I believe I've found a hitch with your suggestion:  what happens when note refers multiples of the same sibling element?  Eg., when <note> is a child of <group> , and  there are multiple <trans-unit>s in that group.  Presumably <note> in this case annotates trans-units in general within that group,  and if you need to annotate a specific <trans-unit> you can do it using a <note> within the specific <trans-unit>.  However,  the same doesn't work in <header>,  where you can have multiple <tool>,  <count-group>,  <reference>  and <context-group>  siblings,  but none of them contains a <note> element.  So if you have 5 different <tool> elements in your header,  what does <note> in the header refer to when annotates="tool"?

I think one way to fix this is:
1. Adopt your suggestion that "annotates" refers to any sibling elements within the same parent structure.
2. add <note> element as a child of any element for which <note> is already a sibling but not a child where the element contains "one or more" of another child element (eg, since its already a child of header,  add it as child of its siblings there:  tool,  context-group,  context,  count-group,  count,  but not glossary,  reference,  skl ;  it's aleady a child of phase,  so we might want to also add it to phase-group)
3. Where more than one instance of the same element exists within a parent,  and note annotates it,  the note will only annotate the element category rather than a specific element.  To annotate a specific sibling where it's possible to have more than one,  the annotation will happen using a note as a child of that element.

This is all rather messy,  and certaintly not as straight forward as I had hoped.  But presently <note> is rather arbitrarily distributed throughout the XLIFF structure so this will at lease make things more logical and symetric.

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.  If we can agree to how to do this with just an addendum to the existing proposal,  then I can just add an addendum to the ballot.  I think we may need one more discussion on this matter,  however - I don't trust email for conducting business of this nature.

The other ballot will still stand (id attrib change from NMTOKENS->string) unless someone can think of a reason otherwise.


John Reid wrote:
I hope you will all forgive my campaigning near a polling place but I
would like to address a couple of issues with the note-annotates

First, the current default value of note is that it annotates the
source. The proposal changes that so that, "The value general is the
implied default." This changes it for all current usage of the note
element and is a broader change than simply adding an attribute. 

Second, as Mark points out, note is used more widely than in a
trans-unit. Thus, it is ambiguous in other locations.

I'd suggest that we should modify the proposal so that note always
annotates its parent and that the values for note are any of its
possible siblings. By annotating the parent in a trans-unit it is also
annotating the source, since the connection between the source and
trans-unit is inseparable. By adding the siblings in all the uses of
note, it may lose the ambiguity Mark mentions.

Tony, did you receive an answer from Karl about what is meant by


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xliff/members/leave_workgroup.php.


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