[
Lists Home |
Date Index |
Thread Index
]
- To: "Costello, Roger L." <costello@mitre.org>, "XML Developers List" <xml-dev@lists.xml.org>
- Subject: RE: [xml-dev] [Summary] Best Practice for URI construction?
- From: "Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>
- Date: Wed, 21 Dec 2005 12:35:59 -0800
- Thread-index: AcYExQ1NnvnJvLKpTSWkv2ut8whc0ABashugAA8CWZA=
- Thread-topic: [xml-dev] [Summary] Best Practice for URI construction?
Hi.
In the absence of a standard way of extracting semantics from URIs, it
seems difficult to make assertions about best practices.
In fact precisely because there is no standard for encoding semantic
data in a URI I would assert that the best practice is to assume that
the URI contains no semantic information and if you do have semantic
information about the resource, encode it in the content returned when
you request the URI, in a format for which some standards do exist for
representing semantics (XML for example).
The example below is very easily interpreted by human eyes. By all
means encode as:
http://www.location.org/US/MA/Boston
in preference to:
http://www.location.org/oadsijfoisadjf3094853094
When given the choice, but realize that for machine processing (RDF
references, namespace URIs, schema locations, etc) neither is
preferable.
In that sense the best practice could be stated "make your URI as
informative to a human reader as you can". Still, from a consumer's
point of view, it would be unwise to deviate from the "URI encodes no
semantic data in itself"
Except maybe:
- slash separated url parts are likely to map to location on a file
system
- query strings (characters after a ?) are likely to be interpreted by
an
application according to the common gateway interface
- anchors (characters after a #) may refer to a fragment of a document
(but are more likely to refer to an empty node in a specific
location)
----------->Nathan
> -----Original Message-----
> From: Costello, Roger L. [mailto:costello@mitre.org]
> Sent: Wednesday, December 21, 2005 6:02 AM
> To: XML Developers List
> Subject: [xml-dev] [Summary] Best Practice for URI construction?
>
> Hi Folks,
>
> Excellent discussions!
>
> I have carefully read all the messages. Below I have
> attempted to summarize what seem to be the conclusions of the
> group. If I have totally missed it, please let me know.
>
> Issue: When constructing a URL, should the "path form" be
> favored, or should the "query form" be favored?
>
> Here's an example of the path form of URL construction:
>
> http://www.location.org/US/MA/Boston
>
> Here's an example of the query form of URL construction:
>
> http://www.location.org?country=US&state=MA&city=Boston
>
> Best Practice: there is no definitive "best practice"
> mandating a certain form should always be be used when
> constructing a URL. Always consider the whole system when
> constructing a URL. That said, there are some general
> guidelines to follow when constructing URLs:
>
> 1. When hierarchy is intrinsic in the identification (naming)
> of a resource then favor the path form of URL construction.
>
> Example: Boston is within Massachusetts, which is within the
> USA. There exists a natural hierarchy in the identification
> (naming) of the Boston resource. Thus, the path form of URL
> should be favored, e.g.,
>
> http://www.location.org/US/MA/Boston
>
> This query form is less favorable:
>
> http://www.location.org?country=US&state=MA&city=Boston
>
> This hybrid form is also less favorable:
>
> http://www.location.org/US/MA?city=Boston
>
> 2. When there is no intrinsic hierarchy in the identification
> or naming of a resource then the query form is favored, e.g.,
>
> Boston may be identified by its latitude and longitude
> (42.358N, -71.06W). There is no intrinsic, natural hierarchy
> between latitude and longitude. So, when using the latitude
> and longitude to identify (name) the Boston resource then use
> the query form:
>
> http://www.location.org?latitude=42.358N&longitude=-71.06W
>
> Comments? /Roger
>
>
|