hello peter.
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.
hm. to me, categories are metadata labels that i can attach to entries, and i am able to require that only certain labels can be used. defining the semantics of those labels as restricting the entry's representation to me looks a little bit like overloading the semantics of categories in a way that is not intended by the spec, and i think its better to clearly separate the category of something (a classification of an entry) from its representation (a constraint on the entry itself). i think i would stay away from this pattern, but i'd be curious to hear what others think about this approach.
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.
i think i understand why you're doing it this way, but i think this couples categories and entries (too) tightly. we would like to use categories in their normal classification role, too, and mixing this usage of categories with the magic "this category constrains the entry representation" categories would results in categories being used for very different purposes.
thanks for the suggestion! cheers, dret.
