Just a few comments on the Pace. Overall, it's cool with me. - Maybe because it was written earlier, it still has references to member-type in the collection element.
- Is label allowed? The only mentioned to label was that one of the examples did not have any labels, but the relax ng doesn't show label attribute is allowed. - fixed? I really don't see the big benefit of specifying it. We could simply say that the server MAY reject new categories, but in reality I don't see that 80% of the implementations would do such a thing. Especially when we are now in a tagging world that results in people being less frugal with categories. Fixed will force implementations to come up with yet another out-of-band mechanism for managing entries. - Maybe add hreflang? - I like less mime-types, just wondering what do you mean by putting them both? service and categories as mutually exclusive top level elements, or a "container" element that has a choice with either or both services and categories? -Elias 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 > > > > > > >
