Re: AtomPub accept

[Jan Algermissen <algermissen1971@xxxxxxx>]

On Aug 28, 2010, at 8:55 PM, mike amundsen wrote:

> Erik:
> 
> It seems to me that you need a new negotiation level here.

Re the other reply. This defines Accept-Features: http://www.faqs.org/rfcs/rfc2295.html

(Not quite what you need, but maybe it is helpful).

Jan


> that
> clients could advertise support for certain kml element and servers
> could respond accordingly.
> for example:
> - kml-accept for a request header
>  contains the list of KML elements supported by the client
> - kml-type for response header
>  contains the list of KML elements returned within the response representation
> 
> These could be included in the Vary header listing to help caches sort
> out the details.
> Advantage is that the details are clearly worked out by both parties.
> Downside is that clients and servers must agree to these new headers.
> 
> Other options could be:
> - clients send KML support information as an argument in the URL
> ?kml={URL-encoded-list}
> - servers generate specific representation of the same map for each
> client and return a Content-Location header that points to the exact
> representation
> - Use Agent-drive conneg: servers respond w/ 300 See Other that
> contains a representation listing all options for this map
> representation based on KML types and the client picks the best fit.
> 
> mca
> http://amundsen.com/blog/
> http://mamund.com/foaf.rdf#me
> 
> 
> 
> 
> On Sat, Aug 28, 2010 at 14:28, Erik Wilde <dret@xxxxxxxxxxxx> wrote:
>> 
>> hello jan.
>> 
>> Jan Algermissen wrote:
>>>> 
>>>> my 2min research did not yield a conclusive answer to this, but it is
>>>> actually possiblt to define a parameter to a media type when the media type
>>>> is already existing and does not have that parameter?
>>> 
>>> The rule should be (though I have no pointer) to ignore unknown
>>> parameters. So, it would be fine.
>> 
>> yes, unknown parameters MUST be ignored, but unless there is some registry
>> for parameter values that can populated with parameter definitions
>> independently of the media type registration, it is hard for developers to
>> understand what some parameter is supposed to mean.
>> 
>>> I was just asking because I had the impression you have a completely human
>>> targeted user agent.
>> 
>> no, we're building an API (targeted on spatial information services) and for
>> our demos we need something that is a UI, but the API should be equally
>> useful for machine-to-machine scenarios as it is for UIs.
>> 
>>> Is there anything in public to read that explains what you are building?
>> 
>> http://dret.net/netdret/publications#liu10a describes the overall design,
>> and we're currently working on a paper that highlights the decentralized
>> nature of our approach (as opposed to many other LBS scenarios that are more
>> vertically integrated).
>> 
>> cheers,
>> 
>> dret.
>> 
>>