Forum OpenACS Development: Re: OpenACS Attribute Management - Requirements/Requests

The major thrust of the differences is that Lee's work was predominantly based on the existing acs_object model and was to allow for the creation of 'typed' attributes (complete with associated tables [content_type] and [content_type_revisions] and associated views [content_typei] and content_typex].

AMS, in contrast, was conceived out of a 'skinny table' implementation that allowed for information (now understood to be called 'generic attributes') to be associated with any object_id. We were intending to do this using the existing data model to the greatest extent possible.

(References below are to previous post)

1. There had been talk of AMS allowing for the creation of new CR content_type(s) but this seems to overlap with Lee's work. We therefore propose to elminate this from the AMS requirements spec. Any 'generic attributes' (I think 'non-typed attributes' would be a clearer description) would  be stored under the control of AMS under pre-defined AMS CR content types.

2.  There seem to be good use cases for having the facility to support permissions at attribute value level. The contacts application is one such example (see contacts requirements doc for full details - should be finished tomorrow!). This would be cumbersome to support using 'typed attributes' and so it is proposed that this be one of the main distinguishing features of 'non-typed attributes' versus 'typed attributes'.

3.  There also seem to be good use cases for having the facility to support revisions at attribute value level. Again, the contacts application is one such example. This would also be cumbersome to support using 'typed attributes' and so it is proposed that this be another distinguishing feature of 'non-typed attributes' versus 'typed attributes'.

This clear delineation of function should avoid confusion, duplication and overlap in the underlying functionality.

There is agreement that there is very likely to be overlap and opportunities for re-use in the user interfaces and the code that generates input specifications for ad_form and perhaps list builder. This provides the best opportunity for saving work and time through code re-use.

We have come to the conclusion (provisionally subject to broad agreement) that the existing permissions system does not lend itself to being stretched to support permissions by attribute value, because this would require every data value to be an object in the acs object model. There is discussion needed to establish the most elegant method of supporting this feature.

If these conclusions and proposals receive support, AMS will form an alternative 'light weight' method for developers to add user customisability to applications with developer defined content_types.

Lee's work will provide the ability for developers to create 'empty vessel' applications that are competely configurable. the advantage of having both systems is that in future, once an 'empty vessel' application has been defined it would be possible for the developer of that application to allow users to add customised 'non-typed' attributes to their content objects with permission control at the value level.

I think that we have now fully characterised the issues and largely resolved them. I hope very much that tomorrow we can finalise the AMS requirements document and progress with designing the data model.

Thank you very much everyone
R.