Re: struct_conn

• Messages sorted by: [ date ][ subject ][ author ]
• Previous message: Paula Fitzgerald: "Re: struct_conn"

In Paula's recent message on the various labels, she says that she
would like to see a world evolve in which sequences are numbered
sequentially and numerically, in which each entity is numbered from
1 to n.  This is _not_ what the mmCIF dictionary says is required
of enitity_poly_seq_num.   It says:

save__entity_poly_seq.num
     _item_description.description
;The value of _entity_poly_seq.num must uniquely and sequentially
 identify a record in the ENTITY_POLY_SEQ list.
 
 Note that this item must be a number, and that the sequence
 numbers must progress in increasing numerical order.
;



This forces a sequential numbering on the entire list of sequences
of entities, i.e. with entity 1 running from 1 to m and entity 2
running from m+1 to n.  This may not be what was intended, but it
certainly is what was said.
This may or may not be a good idea (I actually think it is a good
approach, since it gives an unambiguous handle on the entity_poly_seq
records), but I would plead most urgently that there be no further
changes in the meaning of this token.  This taken has stood and
now been used for a very long time with the present meaning.  To
jigger it for stylistic reasons would invalidate code written on
the basis of what was previously put forward.  Yes, there have
been appropriate warnings not to base code on pre-released
dictionaries, but this is, hopefully, the essentially ready to
release dictionary, and it is now time to swallow hard, accept
any remaining unaesthetic features, and allow, nay, encourage
people to write code based on the dictionary as it now stands
with the firm assurance that all changes from this point on will
be made in a spirit of upward compatability, i.e. that, if it
is at all humanly possible, all further changes will be made
so that they are highly unlikely to invalidate any existing
code, and that CIFs created to comply with the current dictionary
will be accepted as compliant against later dictionaries.  This
may require the use of new tokens and alias, and tie one's hands
in making things mandatory instead of implicit, but if mmCIF
is to become a real, working tool, it must become stable.

• Previous message: Paula Fitzgerald: "Re: struct_conn"