It is my interpretation of the changes document and of the DDLm working group archives that it is not syntactically correct for whitespace to appear between key and separating colon or between colon and value of a table entry in a CIF 2 document. This is a bit ticklish, however, because the values in table entries can be text blocks, which have whitespace (end-of-line) as part of their delimiter.
It is reasonable to account the (one) end-of-line of a text block's opening delimiter as part of its physical value, just as the opening quote of a quoted value would be accounted part of that physical value. By that reasoning, text blocks as table values do not inherently violate of the restriction against whitespace between colon and value. Nevertheless, that makes the language a bit trickier to parse correctly, and it introduces the possibility for strange behavior. For example:
Code: Select all
# valid:
_table1 {'key':
;value1
;}
# invalid:
_table2 {'key':
;value2
;}
Don't be confused if you can't see the difference: that's the point. In fact, the difference is just that in the second table there is a space character after the colon and before the opening newline/semicolon delimiter of the value. (Or at least that's the way I typed it; I think the forum software may be eating the trailing space.)
Also, inasmuch as it is a rather fine distinction to allow text blocks as table values by accounting the newline as part of the delimiter, I think it will be lost on many users why the following is not valid when the _table1 example is:
Code: Select all
# also invalid
_table3 {'key':
value3
}
Is not the newline between key and value there also a delimiter? We even call such values "whitespace-delimited" in the changes document (though that's not an entirely correct characterization; "bare" would be more accurate).
Bottom line: the syntax and grammar as I interpret them can be successfully parsed, but the details in this area are likely to surprise users. Although it is not
necessary to change anything, we should consider allowing arbitrary whitespace (including comments) between the colon and value in table entries.
It is my interpretation of the changes document and of the DDLm working group archives that it is not syntactically correct for whitespace to appear between key and separating colon or between colon and value of a table entry in a CIF 2 document. This is a bit ticklish, however, because the values in table entries can be text blocks, which have whitespace (end-of-line) as part of their delimiter.
It is reasonable to account the (one) end-of-line of a text block's opening delimiter as part of its physical value, just as the opening quote of a quoted value would be accounted part of that physical value. By that reasoning, text blocks as table values do not inherently violate of the restriction against whitespace between colon and value. Nevertheless, that makes the language a bit trickier to parse correctly, and it introduces the possibility for strange behavior. For example:
[code]# valid:
_table1 {'key':
;value1
;}
# invalid:
_table2 {'key':
;value2
;}[/code]
Don't be confused if you can't see the difference: that's the point. In fact, the difference is just that in the second table there is a space character after the colon and before the opening newline/semicolon delimiter of the value. (Or at least that's the way I typed it; I think the forum software may be eating the trailing space.)
Also, inasmuch as it is a rather fine distinction to allow text blocks as table values by accounting the newline as part of the delimiter, I think it will be lost on many users why the following is not valid when the _table1 example is:
[code]
# also invalid
_table3 {'key':
value3
}[/code]
Is not the newline between key and value there also a delimiter? We even call such values "whitespace-delimited" in the changes document (though that's not an entirely correct characterization; "bare" would be more accurate).
Bottom line: the syntax and grammar as I interpret them can be successfully parsed, but the details in this area are likely to surprise users. Although it is not [i]necessary[/i] to change anything, we should consider allowing arbitrary whitespace (including comments) between the colon and value in table entries.