Re: Extensibility strategies, was: Deciding in public (Was: SVGWG SVG-in-HTML proposal)

Ian Hickson wrote:
> Are you seriously telling me that you are worried that people will mint 
> class names intended for non-private use that happen to look exactly like 
> URIs in your domain space?
> 
> If you think that is at all likely, why is it not likely that people will 
> invent class names with your domain name just to spite you, if we required 
> everyone to use URIs?
> 
> I don't want to use URIs. I don't mind if you use URIs. However, it looks 
> to me like you are saying that you want to control what I get to do on my 
> sites. That seems somewhat overbearing.

I think it's clear that you don't want URIs as identifiers. So it seems 
to be pointless to continue this discussion.

>>>>>> How?
>>>>> Using different classes, defining precise behaviour, etc.
>>>> That requires central coordination.
>>> It requires coordination between those who are clashing, yes. Is that 
>>> a big problem? It seems like communication is something humans can do.
>> It's the problem hat distributed extensibility is solving.
> 
> Is it a problem _worth_ solving? Is communicating with a few people who 
> might maybe invent clashing class names such a high burden that we need to 
> optimise our technology stack to avoid it?

Yes.

> Given that the entire point of these unique class names would be to enable 
> humans to communicate, it seems somewhat contradictory to specifically 
> design the system in such a way as to entirely avoid any need for 
> communication. Why is it worth it?

In the one case, you communicate with other peoples who want to share 
this vocabulary. In the other case, you need to communicate with 
*everybody else*, including future generations.

>> I agree that some microformats do fine, but I disagree that they're 
>> doing fine as a generic solution.
> 
> They're not a generic solution. However, they _use_ the generic solutions 
> that HTML provides -- the class attribute, the rel attribute, and other 
> HTML extension mechanisms -- to extend the language in a controlled 
> manner. They don't have to be the only group inventing extensions. They 
> are evidence that the HTML extension mechanism is functional enough to 
> create entire vocabularies and deploy them on major sites.

Again, it doesn't scale, as far as I can tell.

>>> dereference them unnecessarily, causing high load; they are verbose; 
>>> their behaviour in the face of relative URI references causes 
>>> confusion, etc) are well-understood too at this point.
>> They are less verbose when using prefixes.
> 
> To paraphrase jwz, if you try to solve extensibility with URIs, and then 
> try to solve the problems of URIs with prefixes, now you've got three 
> problems. Prefixes don't solve the URI problem, they just exacerbate it, 

There is no "URI problem".

> as has been detailed in depth in the last few days -- people find prefixes 
> inordinately confusing, they add a level of indirection where none is 

People also find class names for CSS confusing.

> needed, they separate the declaration and the use of the name, they split 
> names in two, they introduce their own problem with clashes, and in 

Which problem with clashes? Could you elaborate?

> practice people almost never actually change them from their canonical 
> value, meaning that the majority of the functionality ends up being moot.

It's fine if people do not need to change the canonical prefix. But that 
doesn't mean the mechanism isn't needed.

>> They don't have the dereference problem when a URN is chosen. Yes, these 
>> problems are well understood and solved.
> 
> Why not just use a urn directly then?

A URN is a URI, so I don't understand what you're asking.

>>>>> Why would it not work reliably? Could you provide an example of 
>>>>> something that would be unreliable?
>>>> It would work only reliably if a naming scheme is chosen that makes 
>>>> it impossible that different authors accidentally choose the same 
>>>> name for different purposes. To avoid that, a concrete syntax needs 
>>>> to be defined.
>>> Use URIs.
>> ...that only helps if others do that as well.
> 
> That's only true if you think that others are likely to actually develop 
> class names that look like URIs that clash with your own, something that I 
> believe is far, far, far less likely that the risk of clashes with URIs 
> themselves, e.g. with a domain expiring, being registered by someone else, 
> and having that new owner mint clashing names.

Again: if you fear that issue, don't use a URI scheme that depends on 
the "current" state of DNS, so choose a URN.

It seems you're consistently confusing "URI" with "http URL".


BR, Julian

Received on Tuesday, 5 August 2008 09:56:21 UTC