[Date Prev][Date Next][Date Index]
(5) Procedural refinement
- To: COMCIFS@uk.ac.iucr
- Subject: (5) Procedural refinement
- From: bm@uk.ac.iucr (Brian McMahon)
- Date: Mon, 4 Oct 93 15:12:59 BST
Dear Colleagues A4.3 (see below for explanation and discussion of code) ------------------------------------------------------- It is proposed that our discussions on the one/many file structure of the CIF dictionaries may have reached the stage of a consensual agreement: that separate applications dictionaries be maintained for the foreseeable future, but in a way compatible with their eventual merging into a single file if this should ever become preferable. A4.4 Enumeration values: abbreviations -------------------------------------- It is also suggested that we are in agreement over formalising 'c' as a synonym for 'calc' in the enumeration of _atom_site_calc_flag, and 'y'/'n' for 'yes'/'no' in the *_publ_flag items, these extra values to appear in the _enumeration lists at the appropriate places in the next version of the Core Dictionary. D5.1 Procedural matters ----------------------- David has suggested a way of indexing discussion items based on their first appearance in a communique from Chester, and a way to classify active or resolved matters. Complaints or counter-proposals should be aired within the month (see below!). D> I think that we are off to a good start. We have an excellent D> secretary who manages to put his finger on key problems and usually D> suggest a way to lead us out of these problems. D> D> I think it is time to suggest some refinements to our procedures as D> indicated by the query about how and when we get to vote. Much of our D> business will be done by consensus and I would like to suggest that the D> first item on Brian's messages should be a statement of those items on D> which he thinks a consensus has been reached. There should be a waiting D> period during which any member of the committee can complain that s/he D> does not agree and the matter should be reopened. I would propose that D> the period should be a month to allow for people being away from their D> e-mail for conferences, holidays, etc. At the end of the month Brian D> could formally announce that the consensus has been adopted. This need D> not prevent us in the meantime from proceeding on the basis of the consensus. D> D> Where a matter requires resolution and no consensus is in sight, I will D> ask Brian to call a vote. The details of how that is to be done we can D> work out when a vote is needed. D> D> To simplify back reference to discussions I propose that we adopt a D> number system for Brian's messages so that all points can be referred to D> by the message in which they appeared and the point number within that D> message. Since the last message that he sent (30 Sept) is the fourth (1 = D> 9.15, 2 = 9.21, 3 = 9.27, 4 = 9.30 unless I have missed one), the item on D> restraints would be 4.1. I would further suggest a letter prefix, A for D> matters on which we Agree (consensus) and D for matters that are currently D> under discussion. Therefore the full label for the restraints item would D> be D4.1. I don't want to complicate life with a lot of complex and D> unnecessary labelling, but, in view of the complexity of our task, and the D> fact that Brian's excellent summaries are worth keeping as a record of our D> deliberations, and hence as the minutes of this never-ending comcif D> meeting, a method of referring back to matters of agreement and matters of D> discussion will be very valuable. Matters of substance -------------------- D> D4.2 _intro section. As usual, Brian has come up with an excellent D> solution that seems to solve all the problems and I suggest we accept it. D> I am not sure that I understand his concern about the identical names. If D> this is a problem couldn't the _name be the same as what is on the line D> before, or am I missing something? What is a data block name? Do we need D> some defintions of terms? I do not see this term in the DDL dictionary. D> D> Re Syd's (a)con. Would it not be possible to update the cross referencing D> by computer? All that is needed is to look for the current items in the D> core dictionary that belong to the reuqired catagory. Such an update run D> could be carried out as each new version of a dictionary is released. D> D4.3 How many files: We seem to be agreed on this. Could this be put out D> as a consensus item (e.g. A5.1)? I have a suggestion: would it be D> possible or useful to have, at the head of each file (or data block) a D> listing of the dictionaries that are used in the file? In this way, the D> accessing program would automatically know which dictionaries it needed to D> load. The version numbers should also be included to warn a program that D> it did not, perhaps, have access to the version that was required. I suggest that the original discussion numbering be retained, but the 'D' flag be changed to 'A' to indicate change of status - hence A4.3 (as at head of this message). D> D4.4 abbreviations: Perhaps we have a consensus on this item D> D4.5 Paula's point is well taken. We should encourage people to stick to D> the exact definitions. If they wish to depart in either writing or D> reading a file, they must accept the consequences. D> D> David Brian
- Prev by Date: Restraints; *_intro; etc.
- Next by Date: (6) procedural matters, restraints, dictionary introductions
- Index(es):