Re: URI template: substring for dates

Continuous variables (time, but also space) are probably unsuitable for URI Templates for the reasons mentioned by Mr. Fielding.

The last identifying term does not identify a point in time, but rather a sly duration.  To identify geographic regions by the barycentric coordinate (e.g. the latitude and longitude of City Hall) has the same problem.  I figured out a fix for the geography problem <http://www.rustprivacy.org/primeencoding.zip>, but the time problem will be forever intractable - the left-most term will have to be truncated in order to sort.

The "hash mark" separates the digital from the analog ...

/World/France/Paris (Region)/Paris#AndEverythingThere
/World/UnitedStates/Texas/Paris/MainStreet#AndEverythingThere

Just my 2 cents ...

--Gannon 

--- On Mon, 11/2/09, Roy T. Fielding <fielding@gbiv.com> wrote:

> From: Roy T. Fielding <fielding@gbiv.com>
> Subject: Re: URI template: substring for dates
> To: "James Manger" <James@Manger.com.au>
> Cc: uri@w3.org
> Date: Monday, November 2, 2009, 1:01 PM
> On Nov 2, 2009, at 4:40 AM, James
> Manger wrote:
> 
> > [Comments on the URI Template working draft]
> > 
> > Constructing a URI with a substring of a user-provided
> variable value sounds useful. The current working draft has
> a dictionary site as an example (/dictionary/{term:1}/{term}
> produces /dictionary/c/cat), and mentions hash-based
> storage.
> > 
> > Another important example is dates. Many, many URI
> designs incorporate dates, in quite a variety of ways (just
> year, year/month/day, XML-style timestamp...) -- which
> sounds like a perfect situation to use a URI template.
> 
> Well, not really.  It is fairly common for URI layouts
> to incorporate
> some portion of a date value, such as the year and/or month
> of publication.
> Those are simple variable substitutions like:
> 
>    /post/{year}{month}/{title}
> 
> I have never seen a resource layout incorporate the current
> time.
> 
> In other words, there is no need for the template syntax to
> be aware
> of date fields because (in this case) it is simpler for the
> variable
> values to be limited as such.  String prefix/suffix
> makes sense because
> they are ignorant of variable semantics no matter what the
> values
> might be.  Using substrings to extract fields from a
> date value
> means that we know it is a date value, and thus we can use
> a more
> specific value definition like {seconds} without changing
> the syntax.
> 
> Thanks for the detailed proposal.  I think it would
> make sense if
> we were trying to act like a programming language in the
> template,
> but we are really trying hard to avoid that.
> 
> ....Roy
> 
> 
>

Received on Monday, 2 November 2009 22:06:36 UTC