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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 04 Aug 2008 20:02:07 +0200
Message-ID: <4897441F.5020309@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: 'HTML WG' <public-html@w3.org>

Ian Hickson wrote:
>> If a domain name would be sufficient. So how many people within, for 
>> instance, Google, would want the ability to mint names, and how would 
>> you coordinate them?
> A simple registry in a revision control system, probably, or a wiki.

So the domain name would not be sufficient, right?

>> I'm pretty sure it can easily happen now that new restrictions on new 
>> TLDs have been more or less removed.
> Could you actually give an example where this could happen? I haven't been 
> able to find a case where an actual clash could happen, even with a 
> totally open TLD space.

As the TLD space isn't open *yet*, it's hard to provide that example.

But specifications need to be designed in way that they continue to work 
in the future, right? (I was mentioning this because apparently software 
that supports right-to-left languages already has big issues when 
detecting domain names in context, due to I18Ned domain names, and soon 
arbitrary TLDs).

>>> Consider that even without any sort of disambiguation mechanic other 
>>> than just picking unusual names, Microformats has had no serious 
>>> problems with clashes. If you add domain names to the same thing, the 
>>> problem really becomes moot.
>> The microformats process does not scale. It "works" because it simply 
>> rejects proposals that do not look "common" enough, which of course 
>> reduces the number of potential clashes significantly.
> Microformats scales across the entire Web. That's pretty good as far as I 
> can tell. It's not just clases with other Microformats that matter, it's 
> clashes across all users of classes.

The process doesn't scale, otherwise people wouldn't be sent away just 
because their use case wasn't considered "important" enough.

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


> ...
>>> If the price for that is that you have to use a syntax intended for 
>>> this use, which is in a different _syntactic_ space than the 
>>> language's main vocabulary, is _that_ an acceptable price?
>> Not sure what exactly you mean by "syntactic space". Namespace-qualified 
>> elements *are* in a different space, right?
> I mean that instead of sticking your extension here:
>    <xxxx>
> ...you stick it here:
>    <div class="xxxx">
> It's a different syntactic space than the language's main vocabulary. Is 
> that an acceptable price?
 > ...

If it would work *reliably*, yes. I don't see how it could, as class 
already has different semantics.

>> Point 2: transformations in general are not required to look for 
>> profiles (pointer?). Again, are you mixing up GRDDL (the base spec) with 
>> GRDDL use cases for microformats?
> If transformations are not required to look for profiles, then ignore my 
> second point. Problem solved.


BR, Julian
Received on Monday, 4 August 2008 18:02:54 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:36 UTC