On 5 September 2013 02:48, Paul Eggert <eggert@cs.ucla.edu> wrote:
Stephen Colebourne wrote:
+The file 'backward' consists of Link entries mapping deprecated names +to their replacements. Usage of a deprecated name is discouraged. +As such, the file permits canonicalization
We've never said the 'backward' names are deprecated before. Why start asking users to change names now? We have no plans to remove them.
We've just had a long discussion to achieve the separation described in the proposal. Specifically, that files like zone.tab should not reference IDs in backward. I really want to see that captured so we don't have to repeat ourselves. If you want to weaken the wording, remove the word deprecated for example, I might be open to that. But I do believe that being clearer about why the file exists and what it can be used for by data consumers is helpful. Right now we have three things: - Zone entries - active Link entries, for locations that happen to have the entire local time history of another zone - inactive Link entries, that used to have meaning but are no longer favoured (the backward file) I'm arguing that the Theory file needs to be explicit about the difference between the last two. Not least because that distinction is important to some consumers of the data (I expect to use it to provide some form of canonicalization in JSR-310 at some point for example). BTW, I don't expect one form of canonicalization to be suitable for all, but I do think canonicalizing inactive IDs to active ones is the most sensible form of canonicalization (to avoid political offence for example). Stephen