Re: Categories and fixed="yes"

[Andreas Sewe <sewe@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

> 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>