Issues to be addressed
- Speed issues.
Reading of mmCIF appears to be slow, see e.g. ACT
example. Are improvements possible within ccif framework?
If not, accept or give up?
- Working with subset of mmCIF data items.
CCP4 will provide simple routines to read/write/manipulate a
subset of mmCIF data items. (It should also be
possible to read/write all other mmCIF data items, but we take no
responsibility for these!) Data items which are not explicitly changed
will be copied from input to output, i.e. CCP4 should not cause things
to be lost.
However, this raises the possibility that parts of the mmCIF file
which are manipulated will become inconsistent with parts which are
ignored by CCP4. How do we resolve this? Do other
programs
(such as cif2cif)
care?
- Non-standard use of coordinate files
For example, VECTORS currently uses XYZOUT to store Patterson
vectors as pseudo-coordinates. Strictly speaking, these should
be output as the appropriate data item (but actually, I couldn't
find an mmCIF data item for Patterson vectors!). But then
other programs (e.g. NPO) could not read XYZOUT appropriately.
- e.s.d's
Make functionality available for APs.
- _atom_site.label_seq_id vs. _atom_site.auth_seq_id.
Both can be used for output.
But which does an input "residue range" refer to?
- Return atom label that is composite of chain/residue/atom?
Atom selection stuff.
- Data-item-specific routines + generic ones (in parallel).
Read by column/row.
- Output format of data items.
When CIFOUT is a modified version of CIFIN, altered data items
appear with the default format, which may be different from
that of the unaltered data items. This produces a CIFOUT which,
while perfectly OK for machine reading, is messy for a human
reader.
The default format can be set by the routine CCIF_OUTPUT_FMT.
Should we have a standard CCP4 format and/or allow the user
to set it via a resource file?
- Functionality for CCIF file editor/beautifier
- Dealing with '?' and '.'. Use of dictionary default values.
Back to mmCIF page...