- From: Charles McCathieNevile <chaals@opera.com>
- Date: Mon, 19 Mar 2012 13:30:20 +0100
- To: public-w3process@w3.org, "Giuseppe Pascale" <giuseppep@opera.com>
Thanks for the question, I created ISSUE-5 https://www.w3.org/community/w3process/track/issues/5 ... On Mon, 19 Mar 2012 13:21:45 +0100, Giuseppe Pascale <giuseppep@opera.com> wrote: > Personally I would prefer option 3 below (with option 1 when applicable) [point to a "latest draft" reference]. > The reason is simple: specs tend to be around for a long time and the > references inside may not be updated after the initial work. If this > happens, we end up with some deployments stuck on old versions of a > given spec. I proposed in the HTML group that there should be a "latest version" URI that actually provides a escription of the different kinds of latest version available, from "the editor's sunday-morning mistakes included" to "the last formally stabilised version from years ago, known to be full of errors which are also known", and several things in between. > To mitigate the "moving target" concern I was proposing one of the > following options (non mutually exclusive): For reference guidance (following the principle that deep linking is legitimate, we shouldn't try to limit what people *can* do), I think we should provide something like the same document I describe above, with a recommendation that some baseline is considered for the sake of stability, but with a clear statement that since a later draft may have resolved real problems, the specification of any given feature in the latest draft should also be referenced. Of course there are cases where referencing just some latest draft is enough, and others that will really really only want some old and known-to-be-inferior version for real stability... cheers Chaals > A. mandate support for at least the version available in date X (but not > prevent people to move to a newer spec if available). X could be the > date of publication of the spec that contains the reference. > B. make a generic reference to the specs but "name" the features to > support. e.g. you could say "support the canvas element as specified in > [HTML5]" > > /g > > > On Mon, 19 Mar 2012 13:17:42 +0100, Giuseppe Pascale > <giuseppep@opera.com> wrote: > >> Dear W3C Process Community Group chairs and participants, >> >> we (=Web&TV IG chairs and staff contacts) got a liaison letter >> (attached) >> from the Open IPTV Forum asking about how they should handle >> references to >> W3C specifications that are not yet Recommendations. >> The liaison letter lists a set of options (with pro/cons) and ask the >> W3C >> for advice on how to move forward and how this issue has been addressed >> in >> other cases. >> >> The Web and TV IG held a telco [2] and had some initial discussion on >> possible options. >> There was no consensus on how to deal with the issue but the following >> options (non mutually exclusive) were mentioned: >> >> 1. For all specs referenced by HTML5, indirectly reference them through >> html5 specification (to avoid inconsistencies in references and reduce >> the >> number of open ended references) >> 2. Reference dated snapshots >> 3. Reference a generic undated TF version (e.g. as done by EPUB) >> >> (note: the letter also list other options) >> >> In general, the IG participants felt that was important for the W3C to >> be >> looking into this problem (that is common to many organizations) and >> formulate some policy/best practices. >> That is why I'm fwd this to you. >> >> Do you have any recommendations on this topic or do you think having a >> general policy on this will be in scope of your CG? >> >> >> Regards, >> /g on behalf of the web&tv IG chairs >> >> >> [1] www.oipf.tv >> [2] http://www.w3.org/2012/03/12-webtv-minutes.html >> > > -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Received on Monday, 19 March 2012 12:30:57 UTC