Re: [Uri-review] New icon URI scheme vs new URN namespace

[David Booth <[e-mail]>]

On Wed, 2010-05-19 at 06:58 +0100, Graham Klyne wrote:
> David Booth wrote:
> >> Approach 2 is, prima facie, a preferred route for the web/W3C community's 
> >> preference for using http: URIs (e.g. per 
> >> http://www.w3.org/DesignIssues/LinkedData.html).  But in this case, I think it 
> >> could be an inappropriate overloading of http: semantics, as the proposed icon: 
> >> scheme explicitly defines retrieval semantics that are at variance with defined 
> >> http: retrieval semantics.
> > 
> > No, the retrieval semantics would not be at variance with http:
> > retrieval semantics any more than *caching* is at variance with http:
> > retrieval semantics.  Presumably, there would be one authoritative
> > version of each icon, right?  (Otherwise, what's the point in defining
> > them?)  If the *authoritative* version is identified by an http: URI,
> > but a persistently *cached* version is normally displayed directly from
> > inside the user's browser, this seems to me that it would work *very*
> > well with existing semantics and standards.  And I believe it meets the
> > objective of having standard, URI-named icons that are display directly
> > from the browser (without having to retrieve them over the network).
> > Just think of the browser's treatment of the icons as long-lived,
> > persistent caching.
> 
> I did consider that, but I think the intent of the spec is to allow the browser 
> to choose an icon image appropriate to the platform, which could not be achieved 
> by simple caching.  That is, no *authoritative* version for each icon.  

Okay, so I guess instead of considering it to be the "authoritative"
version of an icon, it should be considered the nominal or "fallback"
version, and the actual version that is displayed may be platform
dependent.

> I 
> suppose one *could* think of such cacheing as being user-agent-dependent (hence 
> Icons retrieved to suit the browser+platform), but this feels to me like it's 
> twisting the circumstances to fit a preference.  (Also, I'm not sure that 
> user-agent-sensitive cacheing is allowed, and if so I suspect it's not widely 
> implemented).

But browsers normally do their own local caching, and that certainly is
user-agent-specific.

> 
> OTOH, an advantage of using HTTP is that it could be supported in browsers that 
> don't recognize the special form of icon URIs, which is a moderately compelling 
> argument.

Yes, it provides a nice fallback.

> 
> I think one may need to review the original end-requirements that the icon spec 
> is intending to address to make a fully rational choice.

Is there a document that describes the requirements or intent more
fully?
http://draft-icon-uri-scheme.googlecode.com/hg/draft-lafayette-icon-uri-scheme-00.html
is a bit sketchy in this regard.



-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.