Change caseless data values to cased for consistency with DDL1. #249
Conversation
In the transition to DDLm it appears that some data names were classed as 'Code' type (caseless) when in DDL1 they were 'char' (always case-sensitive). This patch attempts to identify those data names for which this difference is significant. In some situations, such as data names referring to external database identifiers, the identifiers should be caseless, even if there was no mechanism in DDL1 to indicate this.
|
This pull request is aimed at fixing #245. I have also attempted to catch any other items that were case-sensitive in DDL1 but not in DDLm. I have assumed that references to external identifiers (e.g. databases) are case-insensitive. |
|
Firstly, I wanted to note, that this also reintroduces ASCII whitespaces into the set of symbols that are allowed in values of the changed data items. This increases the compatibility with DDL1 even more, however, personally I somewhat liked the additional restriction of not having spaces in atom labels, etc. Not sure if this is much of an issue for other users, though. Secondly, if I am not mistaken, one of the new desired DDLm features was that enumeration values would be case-insensitive. The current PR version would break this for |
The previous commit accidentally created case-sensitivity for enumerated values, which should not be case-sensitive.
|
Thank you for the changes. So just to confirm, the reintroduction of ASCII whitespaces into the set of permitted characters is not viewed as a problem? |
|
Strictly speaking including whitespace is consistent with DDL1, but I note that mmCIF does not allow whitespace in atom labels. To handle this we would need to invent a new |
|
I will update this PR to use the new 'Word' type for compatibility with DDL1. |
In the transition to DDLm it appears that some data names were
classed as 'Code' type (caseless) when in DDL1 they were 'char'
(always case-sensitive). This patch attempts to identify those
data names for which this difference is significant. In some
situations, such as data names referring to external
database identifiers, the identifiers should be caseless, even
if there was no mechanism in DDL1 to indicate this.