Dave,
Firstly to ease any anxiety :), I agree that we definitely do not want to introduce long delays. Certainly no-one is suggesting years! Actually this needs to be agreed in a matter of days and I know that Matthew needs to progress very quickly for his own requirements. And of course I agree that the simpler the solution the better.
Just to clarify, use case 2 is about ETP which discusses storing a revision as per the current ETP package. It is use case 1 that talks about storing revisions at attribute (i.e. field level) and this was introduced intially because Matthew has/had this as a specific requirement for his own needs.
For my part I am not clear why this particular issue has become so contentious since if all attribute 'values' are associated with a CR object such as 'ams_attribute' the revisioning could be handled consistently and within AMS, without altering anything in connection with the CR API or datamodel. That is to say that the attribute itself is a CR object but the value is not. As we discussed the other day there is no need for AMS managed attributes and values to be stored in the CR standard way with typed tables. In fact the typed tables design does not seem to lend itself to this idea of allowing users to specify data structures within applications.
There is another reason for needing the attribute to be an object which has become clearer whilst writing the Contacts module requirements document. Contacts will need to support personal contact lists, party contact lists and a global contacts list (which will include registered users). We want to avoid lots of duplication of information and take the opportunity to support collaborative data maintenance and updating by having features that verify data wherever a contact appears in more than one party's list. There will be certain fields that one person may keep on a contact that another person does not have or has not been given (a personal cellphone number for example). To support the sharing of data whilst maintaining privacy we need to have permissions set at the level of the attribute so that the system knows which attributes it can show to which users/parties.
Another point of clarification - I know there is already a tcl API for the CR and we are not suggesting re-inventing that. What is meant in the requirements document is that AMS should abstract the developer from the need to create CR objects when using custom attributes via AMS. AMS should take care of everything so that all you have to do is specify your attributes, give AMS your data values and ask for your data values back when you need them
Having said all of that, I still think that we must all agree exactly WHAT we want to build first before we get too involved in this kind of detail. I know it is slightly circular because to some extent it helps to consider the possible ways of doing things when discussing the requirements, however I firmly believe that we will benefit in the long run from writing the objectives down.
You mentioned that you would like to see a more concise and concrete document. I agree that that is important, and so did try to be as concrete as possible, to keep the requirements list short and to give specific examples, for two applications that are actually in progress, of what is needed from AMS (the use case examples). Could you perhaps give me some idea of which requirements you regard as important and which you do not think should be pursued.
Best Regards
R.
