I've got a draft spec for representing a number of common object types in
JSON that I've been working on... basically just defines the conventions...
e.g.
link object:
{
"rel":"...",
"type":"...",
"href":"...",
"hreflang":"...",
"length":"..."
}
category:
{
"scheme":"..."
"term":"..."
}
Was likely going to publish the draft tomorrow.
- James
On Sat, Aug 28, 2010 at 9:45 PM, Peter Keane <[email protected]> wrote:
>
> 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.
> >
>
>
--
- James Snell
http://www.snellspace.com
[email protected]
