W3C home > Mailing lists > Public > www-tag@w3.org > December 2009

Re: [widgets] Authorities will never have authority?

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Tue, 22 Dec 2009 08:50:51 +0000
Message-ID: <4B30886B.2030302@ninebynine.org>
To: Larry Masinter <masinter@adobe.com>
CC: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org" <www-tag@w3.org>
Larry Masinter wrote:
> The only value for authority that doesn't mean
> anything in future versions is to leave the authority
> out completely. It was pretty clear that previously, 
> the 'authority' component was planned for cross-package
> references, and taken out because of security concerns.
> So I think if you want to "future proof" the possibility of
> including an 'authority' or 'query components' in widget:
> URIs, you could do something like
> The URI syntax is
>   "widget:/<path>"

I've noticed that some URI handling libraries don't cleanly handle the 
distinction between no-authority (scheme:/<path>) and an empty authority 

I've also seen the distinction cause implementer confusion (e.g. a recent 
discussion on the Jena mailing list about file:/// - 

I'm not sure what impact such issues might have on the above suggestion.


> but possibly note that future versions might add an
> authority component and a query component.
> "Those who create widget URIs must not include an
>  'authority' or 'query' component. Those who validate
>  URIs must reject, not match, treat as invalid,
>  any URI which contains an authority or a query."
>  "However, implementations which validate widget URIs
>   may note that future versions of this specification
>   are planned which add these fields, so may wish to
>   adjust."
> (Not discussing the "widget:" vs "thismessage:" question
> because the new (but not yet demonstrated) utility
> in "widget:" might have something to do with "authority")
> Larry
> --
> http://larry.masinter.net
Received on Tuesday, 22 December 2009 08:52:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:31 UTC