W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: ISSUE-27: rel-ownership - Chairs Solicit Proposals

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 18 Feb 2010 18:48:20 -0800
Cc: Julian Reschke <julian.reschke@gmx.de>, Ian Hickson <ian@hixie.ch>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
Message-id: <198EF9D7-1778-47EF-BD7E-35160DB3ED61@apple.com>
To: Mark Nottingham <mnot@mnot.net>

On Feb 18, 2010, at 6:07 PM, Mark Nottingham wrote:

> I'm adding:
>
>> Note that relation types MAY be registered by third parties, if the  
>> Designated Expert determines that the relation type is widely  
>> deployed, and the party or parties responsible for introducing or  
>> implementing the relation type have failed to register it in a  
>> timely manner.
>
> Workable?

Sounds like an improvement, thanks.

Though it makes me wonder why there is *any* bias towards the inventor  
or initial implementor of a relation type being the one to register  
it. Apple invented and was the first to implement <canvas>, but Ian  
was the first to define it in a spec. That doesn't seem like a  
problem. As far as I recall, he didn't ask our permission either, nor  
did he wait to see if we would spec it first.

Likewise, it seems like anyone should be register a relation, so long  
as the spec for it is consistent with existing public use. What's the  
reason to have a bias in favor of the originator of a relation type?

My other issue is that this still requires a spec, but if even a very  
rough spec would be accepted, that seems ok.

(I note also that none of this should be taken an objection, it's just  
my opinion, and I do not feel strongly about the details.)

Regards,
Maciej


>
>
> On 18/02/2010, at 12:24 AM, Maciej Stachowiak wrote:
>
>>
>> On Feb 17, 2010, at 5:15 AM, Julian Reschke wrote:
>>
>>> On 17.02.2010 14:04, Maciej Stachowiak wrote:
>>>>
>>>> That would address vendor namespaces, but not registration of rel  
>>>> values
>>>> you find arleady in active use by third parties.
>>>
>>> Yes, that's what I just said :-).
>>
>> The latter is more what I am concerned about, since people make up  
>> rel values all the time without asking anyone's permission.
>>
>>>
>>>>> That's not entirely true, for instance the requirements for
>>>>> provisional URI schemes are:
>>>>>
>>>>> 3. Guidelines for Provisional URI Scheme Registration
>>>>>
>>>>>
>>>>> While the guidelines in Section 2 are REQUIRED for permanent
>>>>> registration, they are RECOMMENDED for provisional registration.  
>>>>> For
>>>>> a provisional registration, the following are REQUIRED:
>>>>
>>>> RECOMMENDED is a lower level of requirement than REQUIRED (a  
>>>> SHOULD, not
>>>> a MUST). I have no problem with a universal SHOULD-level  
>>>> requirement.
>>>> It's just not clear to me that when you can't meet it, the rel  
>>>> value
>>>> should remain completely unregistered.
>>>
>>> I'm aware of that. I was just trying to point out that  
>>> "provisional" doesn't mean "anything goes".
>>
>> No one said it did.
>>
>>>
>>>>> o The scheme name meets the syntactic requirements of Section 2.8.
>>>>> o There is not already an entry with the same URI scheme name. (In
>>>>> the unfortunate case that there are multiple, different uses of
>>>>> the same scheme name, the IESG may approve a request to modify an
>>>>> existing entry to note the separate use.)
>>>>> o Contact information identifying the person supplying the
>>>>> registration is included. Previously unregistered URI schemes
>>>>> discovered in use may be registered by third parties on behalf of
>>>>> those who created the URI scheme; in this case, both the
>>>>> registering party and the scheme creator SHOULD be identified.
>>>>
>>>> This bullet is exactly the kind of thing I think ought to be  
>>>> allowed,
>>>> but effectively is not (unless you are able to reverse engineer a  
>>>> spec
>>>> for the rel value).
>>>
>>> I don't see how this is disallowed for "rel". Write a spec, and  
>>> request registration. What you can't do is specify somebody else  
>>> as relation creator without their agreement.
>>
>> I don't think it's a good idea to leave values in common use  
>> completely undocumented in the registry. It means that a good  
>> samaritan who finds someone else's unregistered header cannot  
>> ensure that it is documented without writing a full specification  
>> that will survive formal review.
>>
>> Like I said, I'm not going to object on this basis, I was just  
>> curious to hear from Mark why there is not any form of provisional  
>> or experimental registration.
>>
>> Regards,
>> Maciej
>>
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
Received on Friday, 19 February 2010 02:48:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:02 GMT