Erik:
It seems to me that you need a new negotiation level here. 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.
>
>
