On Jul 3, 2014, at 1:48 PM, Asmus Freytag <asm...@ix.netcom.com> wrote:
> On 7/3/2014 11:02 AM, Richard COOK wrote: >> On Jul 2, 2014, at 8:02 AM, Karl Williamson <pub...@khwilliamson.com> wrote: >> >>> Corrigendum #9 has changed this so much that people are coming to me and >>> saying that inputs may very well have non-characters, and that the default >>> should be to pass them through. Since we have no published wording for how >>> the TUS will absorb Corrigendum #9, I don't know how this will play out. >>> But this abrupt a change seems wrong to me, and it was done without public >>> input or really adequate time to consider its effects. >> Asmus, >> >> I think you will recall that in late 2012 and early 2013, when the subject >> of the proposed changes (or clarifications) to text relating to >> noncharacters first arose, we (at Wenlin) expressed our concerns. Some >> concerns were grave, and some of the discussion and comments were captured >> in this web page: >> >> <http://wenlininstitute.org/UnicodeNoncharacters/> >> >> There was much back and forth on the editorial list. Discussion clarified >> some of the issues for me, and mollified some of my concerns. >> >> At that time we did implement support for noncharacters in Wenlin, >> controlled by an Advanced Option to: >> >> Replace noncharacters with [U+FFFD] >> >> This user preference is turned on by default. >> >> Not sure if revisiting any of our prior discussion would help clarify the >> evolution of thinking on this issue. >> >> But I did want to mention that the comment “without public input” is not >> quite correct. > > Richard, > > "public input" is best understood as PRI or similar process, not discussions > by members or other people closely associated with the project. Also, in > particular, discussions on the editorial list are invisible to the public. Asmus, The document (L2/13-015, see link above) which we submitted to UTC in response to the original proposal (L2/13-006) advocated caution. When L2/13-006 came to our attention it was perhaps rather late in the game (as Karl suggests in his reply). The changes were perhaps already a foregone conclusion in the minds of the proposers. I don’t recall if anyone even proposed doing a PRI, but in retrospect that would have been good a idea, a PRI would have been ideal and someone should have suggested it. > >> As is so often the case, and as the web page above shows, there was input >> and discussion. Whether the amount of time given to this was really adequate >> is another question. Work required may expand to fill the available time, >> and perhaps more time is now available. > > Given the wide ranging nature of implementations this "clarification" > affected, I believe the process failed to provide the necessary safeguards. > > Conformance changes are really significant, and a Corrigendum, no matter how > much it is presented as harmless clarification, does affect conformance. > > The UTC would be well served to formally adopt a process that requires a PRI > as well as resolutions taken at two separate UTCs to approve any Corrigendum. > > There are changes to properties and algorithms that would also benefit from > such an extended process that has a guaranteed minimum number of times for > the change to be debated, to surface in minutes and to surface in calls for > public input, rather than sailing quietly and quickly into the standard. > > The threshold for this should really be rather low -- as the standard has > matured, the number and nature of implementations that depend on it have > multiplied, to the point where even a diverse membership is no guarantee that > issues can be correctly identified and averted. > > With the minutes from the UTC only recording decisions, one change, to > require an initial and a confirming resolution at separate meetings would > allow more issues to surface. It would also help if proposal documents were > updated to reflect the initial discussion, much as it is done with character > encoding proposals that are updated to address additional concerns identified > or resolved. > > That said, I could imagine a possible exception for true errata (typos), > where correcting a clear mistake should not be unnecessarily drawn out, so > the error can be removed promptly. Such cases usually are turning on facts > (was there an editing mistake, was there new data about how a character is > used that makes an original property assignment a mistake (rather than a less > than optimal choice). > > Despite being called a "clarification" this corrigendum is not in the nature > of an erratum. So, there can be a continuum of cases between erratum and corrigendum. Corrigenda are at the severe end of the spectrum. It should be harder to issue a corrigendum since this affects conformance. Gray areas and thresholds dictate transparent process and caution. Judgement calls in critical cases require entertaining more opinions, and more second guessing, before it is too late. But someone does have to evaluate the possibilities, and make the judgement at each stage in the process. Sometimes too much second-guessing bogs the whole process down. How does the motto go? Is it “Don’t let doing nothing perfectly stand in the way of doing something imperfectly.” ? On the other hand, sometimes the correct response to a call to action is to stand still. Or else somebody invades Iraq and Afghanistan. Can you issue a corrigendum to retract your corrigendum? Or just svn revert the whole software world? -R > A./ >> >> -Richard >> >> >> >> >> _______________________________________________ >> Unicode mailing list >> Unicode@unicode.org >> http://unicode.org/mailman/listinfo/unicode >> > _______________________________________________ Unicode mailing list Unicode@unicode.org http://unicode.org/mailman/listinfo/unicode
