I've just two quick points in response to John's mail: 'self' might be an alternate possibility instead of 'this-file' for the origin attribute and with regard to the state attribute of <target>, should all of the values not be in lower case, in line with our recommendation. Mark Levins IBM Software Group, Dublin Software Laboratory, Airways Industrial Estate, Cloghran, Dublin 17, Ireland. Phone: +353 1 704 6676 IBM Tie Line 166676 John Reid <
jreid@novell.com> 28/01/2003 06:11 To
xliff@lists.oasis-open.org cc Subject Re: [xliff] Working on the Specification Updates Hi Yves, et al, - My point about section 3.2.2 also relates to #8 where I suggest a resectioning of the elements. There are other named groups than those listed and it doesn't really need to be a separate section (IMO). My #8 point is "I've never liked the order I gave the spec." This is not important but I do think it could be reordered a bit, if you agree. - I guess the origin attribute would be enumerated with the 'this-file' attribute value. Maybe this isn't such a good idea? Can you think of a way to implement this concept? - I had suggested the tu-state attribute with values "needs-translation", "needs-review", "needs-resizing", "translation-approved", and "sizing-approved" be added to <trans-unit>. There could be multiple values. I don't like tu-state but I think it was approved. - The above naming was suggested to distinguish it from the state attribute of the <target>. The 'TM-Suggestion', 'MT Suggestion', 'Rejected-Inaccurate', 'Rejected-Spelling', 'Rejected-Grammar', 'Rejected-Length' values were approved for the state attribute. - Maybe we should clarify this better in the meeting ... Should <trans-unit> have the state attribute with "translation-approved" and "sizing-approved" values added? Should a different attribute be added to <target> with the suggested values? Would this make more sense? - How is 'kenavo' pronounced? cheers, john