[DAS] Adjacent feature extension

[Andy Jenkinson]

On 7 Mar 2011, at 10:57, Jonathan Warren wrote:

> 
> My vote would ideally to change feature_by_id to return one feature and have the adjacent_feature as returning one feature. This in my opinion would mean these capabilities on servers do "exactly as they say on the tin" and would be easier to implement for data providers and are thus more likely to be implemented?
> If the feature_id capability as it stands is needed it could be changed to something more akin to what it means like feature_id_region but I would bet no one would bother to change it/use it?
> 
> However the reality is that we are too late to change the old feature_by_id, but I don't think we need to make the same mistake twice by repeating it for adjacent_features? 

I disagree. I think the problems with feature-by-id are that a) the name of the capability implies singular, and b) the concept itself (i.e. getting a feature by its ID) is such a common operation that is otherwise missing in DAS. I don't think either of those apply to an "adjacent" capability unless you specifically choose to call it "adjacent-feature" as opposed to "adjacent-features". I honestly don't think a capability called "adjacent-features" with a query structure like "/das/features?adjacent=foo:1" implies singular, rather the opposite in fact. To me that query suggests "get me the features adjacent to foo:1". True that 2 features is plural which still leaves a "one feature either side" interpretation possible, but IMO certainly not implicit enough to stop anyone implementing it to actually read the specification/documentation. Add to that the fact that this is an entirely new behaviour that we have the chance to properly document and make it clear exactly what the server must do.

So IMO we have a clear choice.

As to feature-by-id, I know changing behaviour is potentially a very disruptive change, but I think we can potentially do this purely because servers don't tend to implement it correctly anyway. Clients can happily filter out any additional features returned by old servers, and if any clients are reliant on the server including all overlapping features then as far as I am concerned they are either a) targeting specific servers rather than DAS-wide and thus unaffected, or b) already broken :)

I have to admit that the feature-by-id capability is one of the (many) things I loathe having to explain and would love to change it. Doing so would be consistent with what we were trying to do with 1.6 (i.e. rationalise existing use of the spec) but I chickened out really.

Cheers,
Andy