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 <[email protected]> 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. >> >>
