Re: [xliff] Problem with the note proposal

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

John: 

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.

Regards,
Tony



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
> proposal. 
>
> 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
> "substantive"?
>
> thanks,
> john
>
> 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