hello mike.
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
i guess we have to discuss this in bit more depth in our team, but my initial reaction to this is that all we need is a way for a server to expose what it is willing/able to accept. clients will have to live with that (as they do in plain atompub), and if they don't support what the server accepts, then they simply cannot edit or create new entries.
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.
i think i'd like to avoid using new headers. it makes an API much more complicated to understand and use for the average web developer, even if it may be an elegant and architecturally sound way to design it.
thanks a lot for your input and the other suggestions! most importantly, i am now pretty certain that there isn't "the one way" that our problem is typically solved in other applications or APIs. we now have to discuss our requirements in more detail, and then will try to come up with a simple and effective way of solving our problem.
thanks and cheers, dret.
