Crystallography Online: the website of the International Union of Crystallography

Thanks all.

>> Bottom line:  I like Brian's rewrite of 55.

I have implemented this. There is of course no intention to encourage 
the use of global_ in the CIF context, but its defensive treatment as a
reserved word minimises the possibility of clashes with any other STAR
applications.

>> 7. A given data name (tag) (see 2.4 and 2.7) may appear no more than
>>   once in a given data block or save frame.  A tag may be followed
>>   by a single value, or a list of one or more tags may be marked by
>>   the preceding reserved case-insensitive word loop_ as the headings
>>   of the columns of a table of values.  White space is used to
>>   separate a data block or save frame header from the contents of
>>   the data block or save frame, and to separate tags, values and
>>   the reserved word loop_.  Data items (tags along with their
>                               ^^^^^^^^^^
>                               This is the correct terminology. Data Items 
> are order independent, not data names. This is true whether data items 
> appear in a loop or outside of a loop.
> 
>>   associated values) that are not presented in a table of values
>>   may be relocated along with their values within the same data
>>   block or save frame without changing the meaning of the data block
>>   or save frame.  Complete tables of values (the table column headings
>>   along with all columns of data) may be relocated within the same
>>   data block or save frame without changing the meaning of the data
>>   block or save frame.  Within a table of values, each tag may be
>>   relocated along with its associated column of values within the
>>   same table of values without changing the meaning of the table of
>>   values.  In general each row of a table of values may also be
>>   relocated within the same table of values without changing the
>>   meaning of the table of values.  Combining tables of values
>>   or breaking up tables of values would change the meanings, and
>>   is likely to violate the rules for constructing such tables
>>   of values.

I've adopted Herbert's wording, and am grateful to everyone for producing
something much clearer than my original draft. Since this is handled in the
section on syntax, discussion is best handled in terms of 'table of values'
rather than 'category', but the result does properly address John's
concerns. It may be that similar statements should be introduced into the
"semantics" document, with the opportunity to say more about the use of
categories in DDL2 applications, but I do not propose to make such a change
at this point.

These changes were intended only to clarify the formal specs: I believe
the topics raised are treated correctly and at greater length elsewhere
in Volume G.

Regards
Brian