Re: Categories and fixed="yes"

[James M Snell <jasnell@xxxxxxxxx>]

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
looking for.

- James

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 [1].
> 
> Ironically, James raised the very same question Joe asks now in April
> [2]: 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 [3] 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: -->
> <app:categories>
>   <app:any/>
> </app:categories
> 
> <!-- Joe's open-ended set of categories in the "foo" scheme: -->
> <app:categories>
>   <app:any scheme="foo"/>
> </app:categories>
> <!-- or (alternatively, using the default provided by
>      app:categories/@scheme) -->
> <app:categories scheme="foo">
>   <app:any/>
> </app:categories>
> 
> 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.
> 
> Regards,
> 
> Andreas
> 
> [1] <http://www.imc.org/atom-protocol/mail-archive/msg09431.html>
> [2] <http://www.imc.org/atom-protocol/mail-archive/msg08999.html>
> [3] <http://www.imc.org/atom-protocol/mail-archive/msg09278.html> and
>     <http://www.imc.org/atom-protocol/mail-archive/msg09296.html>
>