[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Categories and fixed="yes"
Yep, my apologies, y'all are right about what the spec actually says.
It was just a case of me really wanting it to say something else :-).
Unfortunately, at the time, this was one of those things that, at the
time, we only had a limited amount of experience with; not nearly enough
to craft a "complete" solution. This can likely be revisited and it is
possible that the app:categories element can be augmented using
extension attributes and elements that help achieve the goals we're
Andreas Sewe wrote:
>> Bill de hOra wrote:
>>> James M Snell wrote:
>>>> The categories element should be interpreted as only applying to the
>>>> "http://example.org/extra-cats/" scheme.
>>> There's no reasonable reading of the RFC that supports that.
>> To be clear - the scheme attribute exists solely so child category
>> elements without schemes can acquire it. It has no stated relation to
>> fixed, which is relative to the Collection.
> Right, app:categories/@scheme serves only as a default. There is no
> interaction with app:categories/@fixed, just as there is no well-defined
> interaction between multiple fixed attributes .
> Ironically, James raised the very same question Joe asks now in April
> : is there a way to mandate that entries "can [...] contain any
> number of arbitrary atom:category elements that use no scheme at all"?
> The only difference is that James wanted the null scheme to be an open
> ended set, whereas Joe has a non-null scheme in mind.
> Unfortunately, my alternative proposal  which would have been able to
> support both Joe's and James's requirements didn't gain much support
> from the WG.
> <!-- James's open-ended set of categories in the null scheme: -->
> <!-- Joe's open-ended set of categories in the "foo" scheme: -->
> <app:any scheme="foo"/>
> <!-- or (alternatively, using the default provided by
> app:categories/@scheme) -->
> <app:categories scheme="foo">
> IIRC, the above was deemed too complex whereas the RFC's text simply
> seemed to satisfy everybody as everybody interepreted it differently. ;-)
> So let's face it: app:categories/@fixed is not only poorly specified but
> also incapable of satisfying use cases like that of Joe and James.
> All that we can do now is live with it and reject entries which, while
> satisfying the service document's category definitions, do not conform
> to our expectations inexpressible by app:categories. I just fear that it
> means violating a SHOULD once in a while:
> The server MAY reject attempts to create or store members whose
> categories are not present in its categories list. A Collection that
> indicates the category set is open SHOULD NOT reject otherwise
> acceptable members whose categories are not in its categories list.
> The absence of an app:categories element means that the category
> handling of the Collection is unspecified. A "fixed" category list
> that contains zero categories indicates the Collection does not
> accept category data.
>  <http://www.imc.org/atom-protocol/mail-archive/msg09431.html>
>  <http://www.imc.org/atom-protocol/mail-archive/msg08999.html>
>  <http://www.imc.org/atom-protocol/mail-archive/msg09278.html> and