I have used the app:category element to something sort of like this. Per RFC5023 section 8.3.6 (http://bitworking.org/projects/atom/rfc5023.html#categories-elem) a collection can advertise that members should have a particular category to be accepted. Of course you'd need a category schema that mapped to whatever combinations of KML elements were acceptable, then add a "app:category" element to the KML doc itself say it was, say, of the "point+polygon" category. But at least you'd have a standard AtomPub mechanism that a client that knew about it could use.
My use of this mechanism has been a means to "type" atom entries, since we use atom:entry to represent different "types" in the application. Certain collections only accept certain types of atom:entries and that is advertised in the app:categories section of the service doc for the collection. --peter On Wed, Aug 25, 2010 at 8:23 PM, Erik Wilde <[email protected]> wrote: > > hello jan. > >>> still requires some rather static "registration" of those profile names, >>> right? >> >> Yes, that is the idea :-) ... it is all about avoiding coupling clients to >> specific services. Better to couple to a 'standard'. > > 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? it kind of feels > weird, but my media type definition/registration knowledge is a bit rusty in > this particular department... > >>> or could these be any kind of resource, including something like schemas >>> or templates that would be fully self-describing? >> >> IMHO anything will do as long as the specification is a 'standard' (in the >> sense of: not specific to the single service) and as long as it enables >> developers to use the specification when implementing the client and server. >> IOW: developers must understand it > > a schema would be nice because it could be machine-readable, so that there > would be no need to have a predefined set of profile values. you find a > profile URI, read the schema, and then know what additional constraints are > defined for the KML mathing this profile. probably ok, but i am a bit > concerned about the retrofitting of parameters. > >>> 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. >> >> Curious due to some other discussions I have been having: Why did you not >> use HTML to drive your user agent? > > because we are building a feed-oriented API where the main abstraction are > KML-described spatial features, and those are exposed through a > specialization of the general atom/atompub API to collections. for our > scenario, i wouldn't even know ho9w we could utilize HTML. > > cheers, > > dret. > >
