hello jan. On Aug 25, 2010, at 11:42, Jan Algermissen <[email protected]> wrote:
> Preferably, mint a media type. If that kind of information is significant > enough that you want to place it in the accept, media type is the way to go. that's just too static for our scenario, and not really an option. our media type is KML, and essentially we would like to allow different subsets of KML to be accepted, but those subsets could be any combination of KML features. > An alternative is to use a profile parameter (which is essentially media type > 'subclassing'): > <accept>application/kml;profile=http://foo.org/defs/profiles/polygon</accept> still requires some rather static "registration" of those profile names, right? or could these be any kind of resource, including something like schemas or templates that would be fully self-describing? > I am curious: what kind of decision is controlled by your use of <accept>? client behavior, generally speaking ;-) specifically, our UI should only provide tools to create features that then are accepted, so that users don't get a UI that allows them to create polygons, only to have them rejected by the server. our work revolves around managing spatial objects using atom and atompub. cheers, dret.
