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.
Sorry for being late (I had quite a backlog of atom-protocol messages),
but here are some more suggestions:
When it comes to categorization there are really two conflicting
interpretations of "fixed" possible:
1) You are not allowed to use any category other than those explicitly
listed
2) You are not allowed to use any category other than one whose scheme
is "http://example.com/scheme";, i.e., you are free to pick a term,
but not a scheme.
IMHO, both have valid use cases. The first approach would be used to
allow tagging with any category whatsoever, thereby enabling the reuse
of popular category schemes out there. The second approach, on the other
hand, would be used when you want to establish some kind of (loose)
control over your category namespace. The owner of example.com might,
e.g., decide to rename all terms within his "http://example.com/scheme";
so they conform to a particular naming convention (cf. Wikipedia); terms
within another scheme would be beyond his authority.
Currently, PaceAPPCategories only makes the first use case possible. But
you can have both by doing the following:
1) Drop app:categories/@fixed
2) Interpret an atom:category with missing @term as a wildcard, meaning
"you are free to pick a term within this scheme."
That way you can even do things like the following:
<app:categories>
<!-- Any term within my scheme -->
<atom:category scheme="http://example.com/scheme"; />
<!-- or any "Wikipedia term" -->
<atom:category scheme="http://en.wikipedia.org/wiki/"; />
<!-- or any of these two special terms -->
<atom:category
scheme="http://example.org/extra-cats/";
term="joke" />
<atom:category
scheme="http://example.org/extra-cats/";
term="serious" />
</app:categories>
To summarize, I think the above proposal adds quite a bit in terms of
flexibility without any additional complexity. But what do you think
about the above?
That being said, it is not clear to me whether atom:category/@label is
allowed within app:categories. Personally, I think it makes a lot of
sense to have it in there, since, e.g., GUIs might want to use it for
display, but the Pace is silent on it (besides mentioning @label's
absence in the examples).
Last but not least I do not quite understand why categories should be
specified at the app:collection level. IMHO, have an app:categories
element around for each app:workspace ought to be enough. But then again
app:workspace does not have enough semantics attached that I could use
to argue in favor of the latter. ;-)
Regards,
Andreas Sewe
