Erik:
Some ideas come to mind:
If the list of allowed elements is decided solely by the server (e.g.
"we only allow polygons at this server" or "today we accept only
circles and arcs", etc.):
- use a media-type extension specific for your needs:
appcation/kml;allowed="{,,,,,}"
where the value for allowed is a comma-sep list of allowed KML elements
- use the profile extension to point to a document with the list of
allowed XML elements
application/kml;profile="{uri}"
where the document @ {uri} is in a form the client knows (based on
documentation) how to parse for a list of allowed elements
- instruct clients to use the OPTIONS method to return a list of
allows elements via a new header (kml-allowed) and/or the body of the
response
if the list of allowed elements can be actively "negotiated" based on
client capabilities (e.g."oh, i know you, you can only do arcs" or
"all clients from your location are allowed the full list", etc.):
- use the OPTIONS pattern, but require the client to use one or more
request headers to publish client capabilities (kml-accepted)
- expose a resource where clients can POST their capabilities and get
a server response w/ the allowed list (optionally create a hash that
clients must use to validate subsequent writes)
mca
http://amundsen.com/blog/
http://mamund.com/foaf.rdf#me
On Wed, Aug 25, 2010 at 15:14, Erik Wilde <[email protected]> wrote:
> 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.
