IUCr forums

jcbollinger wrote:Are there any objections?

I take most of a week of silence as the absence of objections. I will shortly open one or more new topics dedicated to requirements for the "core" features, and to the extent we can reasonably do so, we will defer discussion of validation details.

That's a fair consideration, but I think it impacts the API implementation more than the design. I realized immediately after I wrote that that there are two separate questions here: ⋅ I offered the possibility that perhaps validation could be addressed via a companion API, which clearly ...

Validation is difficult to add later if it has not been provided for in the initial design. If the concern is efficiency, I would suggest designing on the basis of a validating parser and then providing the option of a bypass of the validation for efficiency. That's a fair consideration, but I thin...

It is perhaps a question better considered later, but we will eventually need to decide on the native language(s) for the API. Having done that, we will have the option of defining bindings to the API for use from other languages. For example, my initial, weak inclination is to target a native C99 A...

Another important scope question is which versions of CIF it will cover. As a practical matter, I think it must support CIF 1.1. Surely it must eventually support CIF 2.0 as well, but should we target that for the the initial version? And to what extent, if any, must the API support documented CIF f...

The first question that occurred to me when I was presented with the idea of a standard CIF API was that of scope. What actions and data structures, generally speaking, will the API provide to clients? Here are some of the things that it might provide: ⋅ Data structures representing CIFs a...

I add my welcome to James's as we open what I trust will be a vigorous, stimulating, and (history suggests) at times contentious discussion.