- From: Lofton Henderson <lofton@rockynet.com>
- Date: Wed, 19 Sep 2007 08:35:25 -0600
- To: "Ian B. Jacobs" <ij@w3.org>,Chris Lilley <chris@w3.org>
- Cc: WebCGM WG <public-webcgm-wg@w3.org>
Ian, Chris -- In haste, because I'm about to leave on travel until the end of next week, and my connectivity will be limited to none. At 01:25 PM 9/19/2007 +0000, Ian B. Jacobs wrote: >On Wed, 2007-09-19 at 15:19 +0200, Chris Lilley wrote: > > On Monday, September 10, 2007, 5:51:47 PM, Lofton wrote: > > > > > > LH> To summarize the below-linked minutes, our recommended strategy is > to get > > LH> 4-week W3C/public review and publish the approved 1.0 errata > document, but > > LH> to skip the hassle of republishing an entire new WebCGM 1.0 Third > Release > > LH> document (Edited Recommendation). > > > > >Today's minutes: > > >http://www.w3.org/Graphics/WebCGM/WG/Minutes/2007/08/30-webcgm-minutes. > html > > > > I heard that the 'approved errata' option was being removed due to not > being used. i have copied Ian Jacobs for an authoritative statement on > whether that can still be used or not. > > > > > > Ian, this is a publicly archived list. > >The option still exists; we have not yet modified the Process Document. >We plan to propose to the AC to remove that option (as it has not been >used). > >I see above "to skip the hassle of republishing an entire new WebCGM 1.0 >Third Release document" Please note that the process for approved >corrections does require publication within 6 months. Can the group >confirm here their intention to publish within 6 months after >the end of the formal review period? The group does not want to republish, and we think that there are good reasons not to republish. Hence our unanimous resolution. However, if we MUST republish, then we will do so. (Timing might be problematic, as the WG charter expires on 11/30.) Rationale. The reason that we did not choose 2.0 to "supersede and replace" 1.0 is somewhat arcane and formalistic. We do not expect anyone to pick up and implement 1.0 anymore. However, there are legacy 1.0 applications and content. For reasons mostly of oversight (omission), 2.0 did not define the 1.0 conformance level (for measuring conformance of legacy stuff). We did not discover until the very end that we had to answer the supersede-and-replace question. It would have taken much work and delay to modify the 2.0 document so that the 1.0 document could die. Hence the only practical choice is that 1.0 remains as a REC. We have identified 11 errata, all but two of which are Class 2. We wanted to simply put those in the errata document (linked from the 1.0 header), and let it rest at that. To republish is likely to be a *lot* of work -- the original 1.0 document was published in 1999, and we reckon that it will take significant effort to update it to current pubrules standards. In the process document [1], [1] http://www.w3.org/2005/10/Process-20051014/tr.html#errata it says: "While the second approach is designed so that a Working Group can establish normative corrections quickly, it does not obviate the need to incorporate changes into an edited version of the Recommendation. In particular, when corrections are numerous or complex, integrating them into a single document is important for interoperability; readers might otherwise interpret the corrections differently." The stated rationales for republication do not pertain, in our view. Our corrections are neither numerous nor complex. Readers are not likely to interpret the corrections differently. 1.0, whether republished or with attached normative errata, will *not* be taken up by anyone for implementation, nor should it be. The sole purpose of (corrected) 1.0 is as a metric for conformance of legacy content and applications, and that is going to be a very rare usage (but formally speaking, it needs to be there). Therefore, we concluded (and Thierry agreed), that we could avoid the large work of republishing 1.0, and instead attach our few corrections. The only reason to republish, in fact, is because of the assertion that the Process requires it. The rationales behind that requirement are lacking in our case. Is there any possibility of process exceptions in cases like this? -Lofton.
Received on Wednesday, 19 September 2007 14:35:14 UTC