RE: [xliff] Version Control Commit by David.Filip

[Yves Savourel <ysavourel@enlaso.com>]

Hi David, all


> Log:
> another interim printout that shouldget us closer to csprd03
> ----------------------------------------------------------------------
> - fixed and finalized the fragment identification mechanism
> - introduced refs in candidates and glossary modules, made corresponding
> changes in the inline annotation sections

I would recommend using separate emails to ask for review rather than the log of the version control: some people filter those email out and may completely miss the request.

I'd like also note that having a single work day to review a large number of changes spread out the entire 127 pages document without being able to see where they are is difficult.

Finally I'd like to note that entering un-approved changes in the draft and getting them approved this way, while possibly is saving some time, is also likely allow to have un-verified changes move to the next draft.
I do realize David does his best to keep up with many changes quickly, and this underline again the risk of un-reasonable deadlines when people do not have the time to met them.

Now onto the comments:

> This should resolve comments
> DONE: 109,

I agree that ids of <unit> must be unique per <file>
I agree that ids of <group> must be unique per <file>
I disagree that ids of <unit> and <group> share the same scope.
(we have not determined that is needed for the URI fragment identifier)

In the other changes made:
I disagree that ids of <note> in units and <note> outside of units should be in different scopes.
(Having different scopes for the same element depending on its location is difficult to implement, and except if the URI fragment identifier requires, is not needed)

I agree that ids of <segment>, <ignorable>, <mrk>, <sm>, <pc>, <sc>, <ec>, and <ph> share the same scope.
I disagree that ids of <data> share the same scope as <segment>, <ignorable>, <mrk>, <sm>, <pc>, <sc>, <ec>, and <ph>.
(same reason as above)

I'll comment separately the new Fragment Identification section.



> DONE: 114,

I don't agree with the constraints as proposed in this latest draft (see issue 109).
But the constraint itself is now defined in a single place so that resolves my comment 114.



> DONE: 126,

New: "When used in a term annotation, the URI value is referring to an external resource providing information about the term."

Please, remove "external": there is no reason to limit the pointed resource to an external one. 



> DONE: 130 

This comment has not been addressed in my opinion.

- The 'match' type for an mrk element should still not be defined in the core as it is used only in a module. The module should define what to use, following the pattern prescribed for mrk type (e.g. something like 'mtc:match').

- I still think we should not have a Translation Candidate Annotation section in the core. It is even less needed now that the Matches module uses its own ref attribute to point to the inline span.

This is an typical example of the specification mixing core and module that we want to avoid to have true modularity.


Regards,
-yves