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

On Tue, 5 Aug 2008, Julian Reschke wrote:
> > 
> > You can use a URI-based scheme.
> 
> But as long as others can use whatever they want, there could be 
> clashes.

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.


> > > > > > > That being said, clashes have occurred (what does the "title"
> > > > > > > class name stand for?), and it's also a known problem that you get
> > > > > > > in trouble once you want to nest information.
> > > > > > These problems are fixable without complicated disambiguation
> > > > > > schemes.
> > > > > 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?

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?


> 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.


> > 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, 
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 
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 
practice people almost never actually change them from their canonical 
value, meaning that the majority of the functionality ends up being moot.


> 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?


> > > > 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 5 August 2008 09:40:49 UTC