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
