hello.
there was a recent discussion about the httprange-14 issue, which
basically asked whether a http-identified resource can be anything, or
just an information resource (i.e., something which by its very nature
can be retrieved through http).
noah_mendelsohn@us.ibm.com wrote:
> BTW: I'm not sure it makes sense to go to far with this discussion here.
> www-tag is a public list, and much of this ground has been covered there.
> If there's more to discuss on httpRange-14, wouldn't it make sense to do
> it on www-tag? Thanks.
sorry for sticking to uri@w3.org, but since i seem to be the one who is
least happy with the puristic http approach to identifying resources, i
would like to expand the discussion a bit. i guess i can live with the
httprange-14 consensus, but even though this consensus allows http
resources to identify anything (as long as they return 303), it does not
say anything about non-http resources.
and since the consensus forces me to use http retrieval to learn about
the special nature of the identified resource, once again i am coming
back to my claim that for sufficiently relevant types of resources
(please note the very vague qualification...), it makes sense to use
non-http uri schemes, because that makes the non-http nature of the
resources transparent (i.e., does not rely on http response codes to
disclose the non-http nature of the resource).
and in a way, shouldn't rdf users be more happy as well if they could
write assertions about geoloc:27.987328,86.923828 when talking about
mount everest, rather than having to rely on the rather awkward
httprange-14 consensus and some mapping service http uri for identifying
the location of the mountain's summit?
i guess i simply still don't quite buy the point that under all
circumstances it would be the better solution to use http uri schemes,
only because they can work against http servers. in the end, i guess it
is simply a matter of weighting. from my point to view, i see this as
follows:
- pro http-based uris: http dereferencable to some http representation
of the resource, more graceful behavior in older clients.
- pro non-http uris: non-http nature of the resource reflected in uri,
no "magic domain names", no requirement for managing the "magic domain
names".
well, i think we have been through these arguments already, and this was
not the information i was originally looking for on this list
(http://lists.w3.org/Archives/Public/uri/2007Dec/0015.html is how this
started), but i would be disappointed to see that the uri space would be
limited to older schemes and new resource types would have to be mapped
to http or introduced as urn (which would turn urns into some kind of
back door to get non-http schemes).
maybe i have to adjust my understanding of web architecture, but i am
still very curious to see how the discussion about geolocation uris will
be received in the web community. personally, i think the web would be
better off to take these resources as seriously as email addresses and
phone numbers and grant them a uri scheme of their own.
happy holidays,
dret.