Bill de hÓra wrote:
James M Snell wrote:
Bill de hÓra wrote:
PaceCategoryListing
+0 only because I am unsure of the mechanism proposed, it looks bloated
(I might come back with questions), but listing categories is valuable.
Bloated? It's one new element with three possible attributes. Could
you explain a bit more about what you don't like?
I think you have to consider the use of the element in the context of
all the workspaces and collections and the number of categories that
might be available. Has anyone who's pro this mechanism considered how
the markup shapes up when you have 50, 100, or 500 such categories to
hand, or what happens when they repeat across collections?
Yes, I've implemented the simple listing with up to 200 categories and
it gets quite cumbersome for large lists. That said, this is not
intended to meet all requirements out of the box. If someone has a
reasonably complex categorization namespace, I would expect them to use
the Out-of-line option to specify an href referencing a resource better
suited to describing that complex categorization.
For example, I'm a lightweight del.icio.us user (going by others use of
it in some blogs I'm subscribed to) and I seem to have used 278
different categories on my links. I have about 50 in my weblog (I have
no idea whether that's a few or lots). I should say I'm not sure if this
pace is intended to scope categories to some level. How do I markup my
50 categories? It doesn't provide any explanation as to why you'd put
categories where it says to put them or how a client can apply them (ie
if there are implicit acquisition rules). Finally, it's not clear to me
whether people won't go off and use collections to de facto map the
categories - it's not like we're providing any guidance as to how to
model the damn things.
I intentionally left out a lot of this detail (and copy-ready text)
precisely because I knew these types of questions would come up and that
we, as a group, would need to discuss them and map out the scope of what
specifically is required. At the very least I wanted to get a pace on
the table with a concrete proposal.
First off, let me reiterate that from my point of view, the core should
provide nothing more than a simple listing mechanism; anything beyond
that should be done as an extension.
Regarding scoping... the answer is yes, if the categories element
appears as a child of <workspace>, it applies to all of the collections
contained therein. If it appears as a child of <service>, it should
apply to all workspaces and collections contained.
Regarding the application of those categories, the semantic is simple:
here are a list of the categories known to be available for this
collection. The list is either fixed or not fixed. A fixed list of
categories means that the server may not accept posts that use
categories not included in the list.
Finally, modeling and management of categories is orthogonal to the
mechanism provided by this proposal. Someone could still use
Collection-based management of categories and use the <categories>
element to bind those to a particular entry collection (or set of
collections). See the third example in the Pace, for instance. Even if
folks do use feeds to map categories, the other issues you bring up
(e.g. scaling, application, etc) are still a problem.
- James
