Re: [ddlm-group] options/text vs binary/end-of-line. .. .. .. .. .... .. .. .

>I don’t understand.  How is it worse to provide authors an opportunity to specify the encoding they have used, even though they may specify wrongly, than it is to deny them an opportunity to specify the encoding at all?

I dont think it is worse to provide them with an opportunity to specify their encoding - I just dont think they should need to.

>How is it a worse or more impactful mistake for an author to include an incorrect encoding tag than it is for them to use an encoding different from some small set that you are prepared to accept?

I am not saying that it is a worse or more impactful mistake - rather, if these signatures are to be part of the standard, then I can foresee errors being raised by an incorrect flag even when the rest of the CIF is encoded according to the specification. In my experience, authors already find CIF slightly annoying in that they have to adhere to seemingly pedantic rules (e.g. 'Monoclinic' should be 'monoclinic' because the dictionary enumeration is case sensitive, or <0.001 is not a number type). Requiring manually edited encoding signatures which will have to be checked is of no real help to anyone (no more than a 'hint')? Again, I feal that we have to respect that in the world of CIF, users have been required to edit raw CIF - this is rarely the case with xml, where end users are rightly unaware of the encoding they are using as they invariably work with tools that shield them from the raw xml. In the short/medium term at least, I do not see this situation changing.

The reason I am prepared to accept 'some small set' is that I would like that set to be unambiguously identifiable, so that authors do not have to worry about such things, and in the hope that non-CIF-aware software might still do a good job of decoding the text, without employing heuristics, thereby minimizing the impact on curent practise of specifying an encoding at all in the new spec.

You might note that I often refer to CIF users as authors - this is my experience I'm afraid. It would be nice if the IUCr could exert as much first-hand control over CIF content as say the PDB, whose online data collection tools are used to populate mmCIFs, and whose users seem quite happy for them to do that. So I stress, my views on this are only based on experience with CIFs submitted to IUCr journals by authors.

>>We're also further restricting the number of non-CIF-aware programs that can be used to read the text.

>Can you expand on that?  I don't follow you.

I was referring to the practice of editing CIFs with any available text editor - however I concede that having an encoding flag makes no difference to non-CIF-aware programs - they will simply save the CIF in whatever is their default encoding if that is how they work.

Cheers

Simon