[
Lists Home |
Date Index |
Thread Index
]
Costello, Roger L. wrote:
> Hi Folks,
hi, Roger
>
> A URI is used to "identify" a resource:
>
> /A Uniform Resource Identifier (URI) is a compact sequence of characters
> that _identifies_ an abstract or physical resource./[1]
>
> I would like to bound the following discussion by considering just URLs
> that use the http scheme.
>
> As I see it, there are two main approaches to constructing a URL to
> identify a resource:
>
> *Approach 1. URL Construction using Parent/Child Relationships*
>
> Here's an example of a URL that uses this approach:
>
> http://www.location.org/US/MA/Boston
>
> After the [host] (www.location.org <http://www.location.org>) there are
> a series of slash-delimited names. The name to the left of a slash is
> the parent. The name to the right of a slash is the child.
>
> *Approach 2. URL Construction using Key-Value Pairs plus Conjunction*
>
> This second approach is exemplified with this URL:
>
> http://www.location.org?country=US&state=MA&city=Boston
> <http://www.location.org?country=US&state=MA&city=Boston>
>
> After the [host] there is the query string delimiter (?) followed by one
> or more key=value pairs ANDed together.
>
> Hybrids of the above two approaches are also possible. For example:
>
> http://www.location.org/US/MA?city=Boston
>
> *Questions*
>
> (1) The above URLs (I believe) are expressing the same thing - they are
it's a convention at http://www.location.org/ : RFCs doesn't say that
they are the same
> identifying the same resource. So which is "better"?
http://www.location.org?country=US&state=MA&city=Boston
http://www.location.org?state=MA&city=Boston&country=US
are the same
http://www.location.org/US/MA/Boston
http://www.location.org/MA/Boston/US
are not
however, it seems that at http://www.location.org/ they decide they are
the same : it's a convention
>
> (2) As was noted at the top, the purpose of a URL is to "identify" a
> resource. Can every resource in the universe be identified using the
> above two approaches? Are there resources that do not lend themselves
> to identification using the above two approaches?
>
> /Roger
>
> [1] http://www.gbiv.com/protocols/uri/rfc/rfc3986.html
>
>
IMHO,
"identify" is not the term that I would use for URLs ; we can say more
precisely that :
URL "localizes" a resource
and URN "names" a resource
what you intend to do is something closer to name than localize when you
use the key-value pairs ; so, URN would be more suitable :
urn:my-scheme:US:MA:Boston
| | |
| | this field is defined as the city
| this field is defined as the state
this field is defined as the country
but it is not usable as-is : it may be used internally, but the
publishing form of this URN could be :
http://www.location.org?country=US&state=MA&city=Boston
or
http://www.location.org/US/MA/Boston
or
http://www.location.org/US:MA:Boston
ha ! this becomes very useless :)
not really : the benefit of such a neutral approach is the ability to
publish your data to multiple targets, that's why I prefer it ; it's
easy with XML to have neutral URIs in source documents and to map them
when publishing
from the client point of view, how to process the URLs ?
in your case, it is obvious that the "fields" can be change with other
values ; this can be done easily thanks to HTML forms, because the HTTP
GET method can produce this kind of URI :
http://www.location.org?country=US&state=MA&city=Boston
but in the other case, it is not obvious from a form to produce it :
http://www.location.org/US/MA/Boston
which requires smart URL manipulation with javascript
so, make your choice ; why don't you use both ?
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
|
