Re: Fwd: New Version Notification for draft-hausenblas-csv-fragment-01

hello dominik.

thanks for the feedback!

On 2012-12-30 13:59 , Dominik Tomaszuk wrote:
> I propose to add "regexp" scheme. For example:
> http://example.com/data.csv#regexp:place=/^G/
> Following the listing in § 2, the above CSV fragment selects a slice,
> yielding another CSV table as follows:
> date,temperature,place
> 2011-01-01,1,Galway
> 2011-01-02,-1,Galway
> 2011-01-03,0,Galway

adding regex support could be regarded as a logical step up in 
functionality from the current slices which use strict matches only. 
however, the general design question is whether sophisticated 
content-based identification is worth the effort, and what the use cases 
are. generally speaking, fragids shouldn't be seen as some form of 
"search mechanism", this can be left to clients by themselves. they 
should mainly focus on identification, and there identifying by location 
usually works fine. we are considering dropping splices all together, 
because they already cross the line into "search land".

interestingly, we had the same discussions when we designed fragids for 
plain text files (http://tools.ietf.org/html/rfc5147). we had the same 
proposals to add regexes and maybe even more sophisticated mechanisms 
(string distance measures, for example) for identifiers that are robust 
against some changes. however, in the end these mechanisms did not make 
the 80/20 cut, and instead an integrity check mechanism was added 
(http://tools.ietf.org/html/rfc5147#section-3.1), so that it's at least 
possible to detect changes in the resource representation.

cheers,

dret.

-- 
erik wilde | mailto:[email protected]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |
_______________________________________________
apps-discuss mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/apps-discuss