[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- From: Joe Krahn <krahn@niehs.nih.gov>
- Date: Thu, 12 Nov 2009 11:47:07 -0500
- In-Reply-To: <C71DF6D4.12389%nick@csse.uwa.edu.au>
- References: <C71DF6D4.12389%nick@csse.uwa.edu.au>
Nick Spadaccini wrote: > > > On 3/11/09 12:53 AM, "Joe Krahn" <krahn@niehs.nih.gov> wrote: > >> Herbert, >> I am only suggesting that maintained Fortran code ought to be able to >> utilize F2003 STREAM I/O, supported by current versions of GFortran, >> Intel Fortran and Sun Fortran. >> >> Of course, I probably am not considering all of the issues. STREAM I/O >> avoids the need for a fixed maximum record length, but even the newest >> Fortran compilers have very limited UTF-8 support. Even with STREAM I/O, >> it is not trivial to count trailing blanks as significant. >> >> Maybe the biggest problem is UTF-8. IMHO, it makes sense for UTF-8 to be >> an optional encoding, rather than just declaring CIF2 is all UTF-8. This > > Not sure what you gain by doing this. If it is pure ASCII only then the > declaration of UTF-8 inhibits nothing, since ASCII is a subset. If it is not > pure ASCII, then it needs to be UTF-8. I can't see how knowing in advance > that it is a subset of UTF-8 or possibly the full set of UTF-8 gives you > anything. > > cheers > > Nick A compiler/language not aware of UTF-8 could avoid errors by rejecting CIF files that contain UTF-8. However, I think the approach being taken is just to allow implementations to restrict usage, rather than put it in the specifications. For example, the plan seems to be that DDL/dictionary definitions will be used to avoid UTF-8 in data names, where it is most likely to be a problem. So, you are right: there is no reason for the CIF2 syntax to make UTF-8 optional when the dictionaries can restrict characters to the ASCII subset. The other potential legacy issues I know of are fixed maximum line lengths, and significant trailing blanks. Dictionary definitions cannot avoid these. It might be possible to take a similar approach, by avoiding them by implementation conventions rather than making it part of the spec. If these are only going to be an issue for a few more years, it would avoid having to make another syntax change in the near future. My main interest here is to avoid incompatible implementations. I also think that Fortran, and any other line-oriented I/O software, should be able to do stream-oriented I/O in the near future. Joe _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (James Hester)
- References:
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Nick Spadaccini)
- Prev by Date: Re: [ddlm-group] CIF-2 changes
- Next by Date: Re: [ddlm-group] CIF-2 changes
- Prev by thread: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- Next by thread: Re: [ddlm-group] Relationship of CIF2 to legacy platforms
- Index(es):