On Sat, Aug 28, 2010 at 7:54 PM, Erik Wilde <[email protected]> wrote: > 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.
I actually agree w/ you here. We've done lots of overloading of atom:category as it seemed to the most natural pure-atom extension point. But ultimately its not really in the spirit of the spec. While I do not regret at all our use of Atom/AtomPub, it served mainly to simply rationalize a growing/evolving system (a digital media repository) and keep us relatively RESTful and enjoying the benefits of some tooling (feed readers, feed validator, Tim Bray's APE, etc.). To that extent it was a good idea. But interop w/ other systems that we didn't control, no so much (other than lots of aspects of our system can be followed w/ a feed reader). I'll be following your efforts closely -- it sounds like a much truer-to-the-spirit application of Atom/AtomPub. I'd been of the belief that Atom/AtomPub was going to be the ideal generic read/write format & protocol that could be almost universally applicable. I've come to believe that the genericity we were after is probably best achieved with intelligent use of JSON (I think CouchDB basically got that right), and that's the direction we are moving in. How to do REST properly w/o JSON being a hypertext format is another can o' worms (which we address simply by using a convention for hyperlinks). --peter > > thanks for the suggestion! cheers, > > dret. >
