+1 to this
Tim Bray wrote:
>
> http://www.intertwingly.net/wiki/pie/PaceAPPCategories#preview
>
> First, I made it relative to protocol-09 and cleaned up a bit of
> language. The Pace was well-received but there were lots of
> suggestions. I made one substantive change: there was a section there
> that I'd never noticed saying that you could have a categories element
> at the workspace level that collections then inherited. This adds
> complexity, and now we have external categories docs to point to, and
> anyhow if you allow this you should probably also allow it at the root
> level to apply to multiple workspaces. Blecch. Gone.
>
> ------------------
>
> Snell (http://www.imc.org/atom-protocol/mail-archive/msg05276.html)
> suggested:
>
> - a "scheme" attribute on app:categories that link to external docs
> - an "exclusive" attribute saying you can only pick one category from a
> scheme
>
> He also suggested the spec include language to talk about partial
> matches; what if I pick a category from the list and change just the label?
>
> I think: Both the suggested attributes fall outside the 80/20 point (in
> particular, only-one-category is a weird special-case), and I don't
> think trying to micro-manage the partial-match scenario in the spec is
> cost-effective.
>
> ---------------------------
>
> Gregorio (http://www.imc.org/atom-protocol/mail-archive/msg05278.html)
> wanted a mime-type, which is reasonable. We already invented
> application/atomserv+xml for introspection docs, and <categories> isn't
> in the atom namespace it's in the app namespace. I suggest we drop
> app/atomserv+xml and put both <services> and <categories> in
> application/app+xml and I've updated the Pace. Thoughts?
>
> Joe also asks whether we need to discuss what app:categories might mean
> if it showed up in an Atom Feed or Entry doc. I don't think so.
>
> --------------------------------------
>
> Broyer (http://www.imc.org/atom-protocol/mail-archive/msg05297.html)
> agrees with me on Snell's first suggestion, and also wants more than one
> <categories> element in a app:services/collection. I think multiple
> categories is easy to understand and I've added it to the Pace. He also
> points out that this raises the issue that you might want have somewhere
> to put a "fixed" attribute to say you have to choose from one of the
> categories elements, and suggest an app:categoryGroup element to do
> this. I think that's over the 80/20 border.
>
> ---------------------------------------
>
> Check out Snell's proposal in
> (http://www.imc.org/atom-protocol/mail-archive/msg05298.html). He wants
> a categories/scheme/category hierarchy, which addresses Broyer's issue.
> But it makes the data model more complicated and then you have to figure
> out where to put the href. So I think that multiple categories hits
> the 80/20 point and achieves most of the same benefit.
>
> From there on, discussion went into a maze of twisty little passages
> chewing over James' proposal.
>
> -Tim
>
>
>
>
>
>
>
