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: Tue, 05 Aug 2008 11:14:54 +0200
Message-ID: <48981A0E.6010000@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: 'HTML WG' <public-html@w3.org>

Ian Hickson wrote:
> ...
>> This can be avoided by mandating exactly one scheme.
> 
> It can also be avoided by allowing people to use any schemes, so long as 
> those schemes can't be confused with each other. For example, 

If you have a combination of multiple schemes that can not be confused, 
than you essentially *have* a single scheme.

> com.example.word and word.example.com are both sensible schemes, but 
> example.com.word wouldn't really be a good scheme. So if someone uses a 
> sensible scheme, they are ok.

Except for the problem explained earlier.

>> A URI-based scheme would be a candidate, and have the advantage that 
>> those are well understood and are used almost everywhere else (which 
>> makes roundtripping easy).
> 
> You can use a URI-based scheme.

But as long as others can use whatever they want, there could be clashes.

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

>> As far as I can tell, the problems with microformats are well understood 
>> by now (nesting, abuse of title attribute, process only works for a few 
>> common formats), but it seems you prefer to ignore them.
> 
> It's not clear to me how I am ignoring them, or what it would mean to not 
> ignore them. Despite all their problems, as you put it, Microformats are 
> doing fine. The problems with URI-based extension mechanisms (people 

...not for everybody...

I agree that some microformats do fine, but I disagree that they're 
doing fine as a generic solution.

> 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. They don't have the 
dereference problem when a URN is chosen. Yes, these problems are well 
understood and solved.

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

BR, Julian
Received on Tuesday, 5 August 2008 09:15:39 GMT

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