yayahjb wrote:Returning to the "core" features. I would suggest considering
(1) Open, read, update, create, close, delete a CIF file with or without supporting dictionaries.
(2) Open, read, update, create, close, delete one or more datablocks withing a CIF file
(3) Open, read, update, create, close, delete one or more saveframes within a CIF dictionary
(4) Open, read, update, create, close, delete one or more categories within a datablock or saveframe
(5) Open, read, update, create, close, delete one or more rows or columns withing a category
(6) Open, read, update, create, close, delete one or more data values at specified rows and columns
(7) Features to view and control layout of a CIF, including whitespace and comments
(8) Utilities for conversion among CIF and other useful formats, such as XML and HDF5
(9) A CIF editor based on all of the above as a demonstration of the use and capabilities of the API
It the API will not support an editor, it will have trouble supporting a wide range of aps.
I'm about to be rather nitpicky; please don't take it personally. Anyway, one or two of these comments apply similarly to James's list.
What is the significance of opening a CIF file that is separate from reading or writing it?
Is there any reason to have a close CIF function, other than that a standalone open CIF function is proposed?
Why does our API need to address deleting a CIF file? Is that not adequately covered by the OS and / or standard library?
What is the intended meaning of opening, reading, or closing a data block, independant of file-level operations?
What is the intended meaning of updating a data block, independent of both file-level and lower level (3 - 6) operations (i.e. what's changes)?
What is the intended meaning of opening, reading, or closing a save frame, independant of file- and block-level operations?
What is the intended meaning of updating a save frame, independent of both higher-level (1-2) and lower level (4 - 6) operations (again, what changes)?
Does the specifcation that these operation apply to a CIF dictionary consitute anything more than a simple recognition that only dictionary CIFs, not data CIFs, are permitted to contain save frames?
"Category" is a DDL concept, not a CIF concept. Is it intended in this context to mean anything different than what I might describe as a "loop"?
What is the intended meaning of opening or closing a category?
What is the intended meaning of reading or updating a category, independent of the higher-level and lower-level operations?
What is the intended meaning of opening or closing rows or columns within a category?
What is the intended meaning of opening or closing data values at specified coordinates?
What is the intended meaning of creating or deleting data values at specified coordinates, independent of creating or deleting rows and columns?
What makes this consideration independent of the previous ones, especially (1)?
Regarding (8) and (9):
These are not CIF API features at all, they are independant programs. It might be reasonable and even wise for such programs, based on our API, to be distributed with API implementations, but they are in no way appropriate to include in the core API requirements.
How do these requirements address unlooped data? Is that subsumed into the concept of "category"?