W3C home > Mailing lists > Public > public-html@w3.org > August 2008

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 5 Aug 2008 10:14:33 +0000 (UTC)
To: Julian Reschke <julian.reschke@gmx.de>
Cc: 'HTML WG' <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0808050958360.5136@hixie.dreamhostps.com>

On Tue, 5 Aug 2008, Julian Reschke wrote:
> >
> > 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.

I could equivalently say "I think it's clear that you want URIs as 
identifiers. So it seems to be pointless to continue this discussion", but 
that wouldn't be very productive.

What I don't understand is why while I think it's fine for people who wish 
to use URIs to do so, you seem to think it's not ok for people who _don't_ 
wish to use URIs to _not_ do so.

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 or URN space?

If you think that is at all likely, why is it not likely that people will 
invent class names with your domain name or URN space just to spite you, 
if we required everyone to use URIs?


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

Why?


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

Not at all. You only have to communicate with the people who have any 
chance of clashing with you, for example if you are using a scheme like 
"word.example.com", you only have to talk with people on "example.com", or 
if you are using a scheme like "ab.cd-word" you only have to talk to 
people on "ab.cd" and "cd.ab".

Is this an undue burden? Why?


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

Why would they scale any worse than any other scheme? I don't understand 
what it is you think doesn't scale here. Don't forget that you don't have 
to use the naming scheme Microformats use. You can use URIs if you like.


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

If there's no problem, what are prefixes solving?

The URI problem is that they are too verbose.

(They have other problems as well, as I said recently and as you quoted 
above, e.g. people get confused with relative URIs, people who use HTTP 
URIs -- most people, in practice, for namespaces -- get confused about 
when or how to derefernce them, etc.)


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

Indeed. Let's learn from our mistakes instead of adding more.


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

To demonstrate this in XML, consider this document:

   <a:foo xmlns:a="http://a.example.com/">
    <a:bar/>
   </a:foo>

...and now consider this fragment:

   <a:quux xmlns:a="mailto:ian@hixie.ch">
    <a:bar/>
   </a:quux>

If I try to copy the <a:bar/> from one document to another, then it'll 
change namespace unless I go out of my way to fix up the prefix 
declarations.

Or similarly, if I have:

   <x xmlns:a="http://a.example.com/">
    <z a:test="..."/>
   </x>

...and:

   <x xmlns:a="mailto:ian@hixie.ch">
    <z a:test="..."/>
   </x>

...and I try to merge these two documents, then unless I fix up the 
prefixes, I end up with a problem with the two attributes.

None of these problems exist if you don't have prefixes.


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

I mean without prefixes, just stick the unique value in the class 
attribute.


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

How do you propose to have a distributed extension system with URNs, if 
you're not using the domain name system to guarantee uniqueness? Aren't 
you just trading one central repository (the HTML WG) for another (the URN 
registry)? Could you elaborate on how you see this working?



At this point, to be honest, I've lost track of what you're trying to 
solve and why the existing mechanisms don't solve them. If there is no 
risk of people making up URNs that clash with yours, then why can't you 
just use URNs in the class attribute as your extension mechanism?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 5 August 2008 10:18:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:57 UTC