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 13:49:59 +0200
Message-ID: <48983E67.8080004@gmx.de>
To: Ian Hickson <ian@hixie.ch>
CC: 'HTML WG' <public-html@w3.org>

Ian Hickson wrote:
> On Tue, 5 Aug 2008, Julian Reschke wrote:
>> If you think it is so unlikely, why not make a statement that something 
>> that parses as a URI must be a URI under the control of the party 
>> minting the identifier?
> Would this resolve your use case?

It would make it better, but I wouldn't still be happy with that approach.

>>> (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.)
>> You don't dereference them (automatically). Put that into the spec, and 
>> there will be no confusion.
> Unfortunately, saying that doesn't help in practice. q.v. the W3C's load 
> problem due to people dereferencing URIs that shouldn't be dereferenced.

Is that about URIs as used in identifiers, or about URIs pointing at DTDs?

>> So, out of curiosity, what would be a better design for CSS?
> I have no idea. People have a big problem with the indirection of having 
> the semantics/structure in one document and the style in another. I don't 
> know how to solve this, though, as the split is too advantageous to lose.


>>> 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?
>> I recommend reading the URN specs. For instance, the namespaces below 
>> "urn:isbn", "urn:ietf" and "urn:uuid" are controlled by different 
>> entities (or for the case of UUIDs not controlled at all).
> As far as I can tell, none of these would allow you to invent your own 
> vocabulary without first contacting a centralised registry.

urn:uuid does, at least when using a pair of URI and local name as 
identifier (as common in XML).

Another scheme, although defined for something else, that can be uses is 
"opaquelocktoken", which uses a UUID *plus* a postfix you can control.

>> In particular, the "tag:" URN scheme solves the DNS issue by adding a 
>> timestamp
> That seems just slightly more verbose than an HTTP URI.


>> I'd prefer
>> - the spec to give rules for the formats of these names, so clashes are 
>> avoided (if you use a URI, use one you have authority over), and
>> - a more compact syntax (be it QName, CURIE, whatever).
>> And of course I'd really prefer a mechanism that uses the same syntax as 
>> in other markup languages, obviously (or is as close to them as 
>> possible).
> Are all three of these requirements absolute requirements, or would you be 
> satisfied with, say, just the first?

The first one IMHO is essential; the other "only" affect readability.

> Here are my requirements:
>  - that the extension mechanism have a fallback mechanism for 
>    accessibility, e.g. so that you can give a "nearest equivalent HTML 
>    element" for each extension.

Sounds like a good thing to have; not sure whether it's always required.

>  - that the extension mechanism be easy to use, e.g. not use any kind of 
>    indirection, not split the names up to distant parts of the document

"easy to use" is subjective. For instance, with XML namespaces you can 
still have the names on the same element; you don't *need* to split them 
into distant parts.

>  - that the mechanism work or fallback gracefully in legacy user agents

I think it would be sufficient if it works in HTML5 UAs.

>  - that the mechanism allow authors to use whatever naming scheme is most 
>    convenient for them

...as long as there's a *reliable* way to mint identifiers, I don't mind 
when people choose not to use that mechanism. As long as they can't 
create collisions with the aforementioned ones.

> I don't think we can hit all seven requirements simultaneously. If you 
> have any proposals, I'm certainly eager to hear them.

BR, Julian
Received on Tuesday, 5 August 2008 11:50:42 UTC

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