[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff] 1.2 to 2.0 Gaps and Proposals
Hi Shirley, it was agreed in last week’s TC call that we would merge our feature requests:
3.1. (S1) Change Tracking / Version Control
1.19. (R43) Change track module
Can you let me know what your ideas are for this module and maybe we can take the discussion offline for a bit to come up with a proposal for the structure and PR of the module? Our initial requirement was simply two properties that would record the author and timestamp of a piece of data, such as a source segment or a note.
From: Dr. David Filip [mailto:David.Filip@ul.ie]
Ryan, one very short comment below..
This could not work from the point of view of the normative theory. You cannot have "MUST preserve" and "SHOULD update" statements on the same level.
The working should be like this:
[This is the same in general for ALL module PRs]
So what you wanted to say is probably that the tools MUST preserve if they are unable to process according to the module specific PRs, but this is equivalent with the general PR that the TC adopted by the last completed ballot, so all should be OK :-)
Sorry, if this seems hair splitting, or if it seems self-evident to everyone, but I believe this is vital and beneficial to clarify at this point for all module owners, so that they understand the relationship of their module specific PRs to the general MUST preserve PR defined at the core spec level.
A related issue occurred in the discussion between Yves and myself before TC made the decision on general PRs. Yves thought that it was absurd that only module implementers can remove module, I argued that this is exactly what we wanted to achieve and this is what prevailed in the ballot.