hello mike.
mike amundsen wrote:
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
that might be a bit too rigid, but i think we haven't even fully made up
our minds what kind of constraints we want to be able to encode.
- 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
that sounds more flexible and powerful and was what jan suggested; i am
still a bit unclear, though, how "profile" would become a well-known
parameter for the KML media type. i tend to think that you cannot just
retroactively register additional parameters for an already registered
media type, but i may be wrong.
- 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
but would this still count as atompub?
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.):
no, this is not in our requirements. we want a service to be able to
expose what it accepts, and clients will have to deal with that.
thanks,
dret.
