Re: [ddlm-group] How to specify syntax of a number in CIF2

Hi James,

I support your enumerated objectives, but your proposed changes seem at odds with objective (2), with widespread DDL1 practice, and possibly even with standard DDL2 practice.  I’m up for clarifying and for making recommendations, but not for making changes that invalidate significant bodies of current software or practice.  Moreover, the proposed additions don’t address all the issues.

Without getting into specific language, this is what I think I would like to see:

() a clarification for ITVG 2.2.7.1 (10) explaining that "values that are to be interpreted as numbers" refers specifically to values interpreted, for whatever reason, according to the data type 'numb' described in section 2.2.7.4.1.

() a clarification for ITVG 2.2.7.4.1 that explicitly narrows its scope to items not defined in a dictionary.

() a clarification that the CIF 1.1 <Numeric> production and its related component productions provide the details of the conventional data type 'numb', as opposed to being the only allowed form for numeric data values, regardless of actual data type.

() a clarification that a dictionary *can*, without restriction, ascribe any significance to whether a value is presented quoted, paired with a recommendation that they *not* do so, and perhaps a description of the limited ways in which the current DDLs and dictionaries do do so.

() a secondary recommendation that dictionaries that do ascribe significance to whether a value is presented quoted do so as broadly and uniformly as possible.  Examples of broad and uniform would be overall dictionary-level, or even DDL-level recognition of the conventional CIF null values as distinct from their quoted analogs, and similarly-scoped specifications that numbers be presented unquoted.  We especially want to discourage such distinctions being drawn on an item-by-item basis, but I don’t think that’s a major problem because none of our DDLs has a means to express that.

() an adjustment to the prose definition of DDL1's '_type' attribute, which is anyway either incomplete or inconsistent in version 1.4.1 of that dictionary, as it pertains to type numb.  This could provide format details for the general case, to be narrowed where necessary by other definition attributes.

() a recommendation to CIF authors (but mostly to their proxies, authors of software that outputs CIF) that numeric data values be presented unquoted wherever their data types permit.

() a recommendation to authors of software that reads CIF to accept quoted numeric data values, even when their data types do not actually allow it.  This is not meant to preclude software issuing diagnostic messages warning about malformed numeric values in the event that values are presented quoted when their items' definitions demand otherwise.

() a recommendation to CIF dictionary authors that the defined format for numeric data types be consistent with the ITVG numeric syntax wherever possible.

Looking forward to the next edition of ITVG -- and with apologies to the section 2.2 authors, many of whom I know are receiving this -- I think section 2.2 would benefit from a thorough rewrite.  Minor tweaks here and there won’t really suffice.  The current version is a concatenation of two distinct documents with overlapping subject matter coverage, drawing on document history and lineage that extends to a time before that of some of the material it is intended to specify.  It is needlessly repetitive, and it emphasizes some details that these days are of minimal importance.  As the discussion here has shown, it is also tricky to interpret in places, and it struggles a bit to accommodate both DDL1 and DDL2 practices.  It will face an even bigger challenge in the next edition, with the addition of CIF 2.0 syntax and DDLm (albeit probably in a different section).  I suggest, therefore, that we not worry at this point about prose for that edition, but instead work on making the best we can of the current edition by providing written interpretations and, if necessary, corrigenda.

Regards,

John