@All module owners (i.e. feature owners, whose feature was specified as a module), as part of the spec sanity check, please review "your" module PRs. In particular, make sure that your module PRs state how your module can be introduced, updated AND deleted. @Yves, if a module spec does not specify how it (its elements, attributes, values) can be removed, it is not an issue of the general PRs but of that very module. It would be lame to leave this to SHOULD and tribal knowledge rather than explicit definitions and PRs Cheers and weekend dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734 mailto:
david.filip@ul.ie On Sat, Nov 17, 2012 at 1:55 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: > ... 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. And on that note David: Following that logic, since none of the modules has currently any PR stating a tool implementing the module can remove the element, technically, once added a module element cannot be removed ...ever. Even by the tool that placed it there. That's the problem with "MUST preserve" at the default level: It forces you to define module-specific PRs where you can't possibly think about everything. That results in default PRs that are simply impossible to enforce. But it's ok, I'm past spending time discussing it. Have a good week-end, -ys --------------------------------------------------------------------- To unsubscribe, e-mail:
xliff-unsubscribe@lists.oasis-open.org For additional commands, e-mail:
xliff-help@lists.oasis-open.org