Re: Normative references to non-recommendation specs

Hi,


On Feb 17, 2011, at 10:03 AM, Andrei Popescu wrote:

> Hi,
> 
> On Wed, Feb 16, 2011 at 2:32 PM, Lars Erik Bolstad <lbolstad@opera.com> wrote:
>> The W3C transition steps documentation says that a "In general, documents do
>> not advance to Recommendation with normative references to W3C
>> specifications that are not yet Recommendations." [1]
>> 
>> We currently have normative references to HTML 5 ([BROWSINGCONTEXT],
>> [DOCUMENTORIGIN], and [NAVIGATOR]), as well as to WebIDL.
>> None of these specs are Recommendations and these references could therefore
>> block our transition to PR.
>> 
>> We could replace the [DOCUMENTORIGIN] with a reference to RFC 2396 if we
>> actually go ahead and change the wording in section 4.1, as previously
>> discussed.
>> 
> 
> Done:
> 
> http://dev.w3.org/cvsweb/geo/api/spec-source.html.diff?r1=1.91&r2=1.92&f=h

Thanks Andrei!  Sorry I didn't catch this earlier, but we should refer to RFC 3986 [1], which is the latest URI RFC.  It seems to have effectively the same definition of host.


> 
>> I don't know how or if we could get rid of the other references, though, nor
>> if the "In general" qualification means that exceptions can be made. Matt,
>> could you perhaps share some thoughts on that?
>> 
> 
> I am not sure there's much we can do about that. Can we get an
> exception from W3C for this case? :)

I would think that for the text referencing BROWSINGCONTEXT [2] that since it's used parenthetically and in an "i.e." statement, that we could make the reference itself non-normative.

Looking at the NAVIGATOR reference [3], we don't have any dependency on what's within the navigator object, so it doesn't feel like a strong dependency.  I don't have a concrete way to change the text to reflect that, but if we did, I believe we could make it a non-normative reference.

The WebIDL problem is not as easy.  We could fallback to what specs did before IDL (e.g. DOM [4]) did and use the OMG IDL.  This would require rewriting our WebIDL to conform to OMG IDL which is lossy.  So, we would then have to add new text that effectively re-establishes the JavaScript bindings and any other features which were lost by stepping back to IDL.


-Matt Womer

[1] http://www.ietf.org/rfc/rfc3986.txt
[2] http://www.w3.org/TR/2010/CR-geolocation-API-20100907/#privacy_for_uas
[3] http://www.w3.org/TR/2010/CR-geolocation-API-20100907/#geolocation_interface
[4] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/references.html#OMGIDL

Received on Monday, 7 March 2011 14:56:38 UTC