I need to look at this in more detail.
But there is one thing that I will say, knowingly speaking to a deaf
audience on this list. If you were to use RDF your life would be soo
much simpler. There would be no need to keep inventing new file formats.
In fact I am starting to be convinced that REST without RDF is only
somewhat less hopeless than SOAP.
Every single format that people invent is going to have to be
debated. The more such formats exist the more difficult it is going
to be to make sure things work together properly, the more difficult
it is going to be to understand what is happening.
If you use the AtomOwl vocabulary you can create the right format in
N3 or rdf/xml in a few seconds, and any rdf parser would be able to
understand it immediately.
Henry
On 7 Jul 2006, at 22:34, 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
