[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: Nick Spadaccini <nick@csse.uwa.edu.au>
- Date: Fri, 20 Nov 2009 12:07:36 +0800
- Authentication-Results: postfix;
- In-Reply-To: <alpine.BSF.2.00.0911191016360.75409@epsilon.pair.com>
Just as James changes his vote to 2048 :) I suggest we leave it at 2048 bytes, because (a) it's long enough (b) we will have at least one thing we WON'T change from the CIF1 specification. Nick On 19/11/09 11:19 PM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com> wrote: > Just to simply the menu of choice, I'll change my vote to 4096. -- > Herbert > > ===================================================== > Herbert J. Bernstein, Professor of Computer Science > Dowling College, Kramer Science Center, KSC 121 > Idle Hour Blvd, Oakdale, NY, 11769 > > +1-631-244-3035 > yaya@dowling.edu > ===================================================== > > On Thu, 19 Nov 2009, David Brown wrote: > >> I have no strong views on line length, but the arrguments for keeping them >> seem a little stronger than those for abolishing them. I have no views at >> all on how long the lines should be other than to note that Acta Cryst. >> programs get upset if there are more than 80 characters in a line. >> >> David >> >> >> >> James Hester wrote: >> >> We should resolve the Fortran line length issue as I think we've got >> enough information on the table - could those who haven't indicated >> their preference please vote either >> >> (1) CIF2 should have a maximum line length specified or >> (2) no line length should be specified. >> >> For bonus points, you can indicate what this length should be. >> >> So (including Nick's recent email) I count the votes as: >> >> (1) Herbert (>=2048), Nick (2048), James (4096) >> (2) Joe >> >> I've added my vote to the fixed line length simply because I accept >> Herbert's argument that legacy Fortran programs are actually important >> in the crystallographic world, and a restriction on line length does >> not impose a burden on CIF readers. It also imposes a bit of >> discipline on CIF writers and helps to produce a readable file. >> >> On Fri, Nov 13, 2009 at 3:47 AM, Joe Krahn <krahn@niehs.nih.gov> wrote: >> >> 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 >> >> >> >> >> >> >> >> >> > _______________________________________________ > ddlm-group mailing list > ddlm-group@iucr.org > http://scripts.iucr.org/mailman/listinfo/ddlm-group cheers Nick -------------------------------- Associate Professor N. Spadaccini, PhD School of Computer Science & Software Engineering The University of Western Australia t: +61 (0)8 6488 3452 35 Stirling Highway f: +61 (0)8 6488 1089 CRAWLEY, Perth, WA 6009 AUSTRALIA w3: www.csse.uwa.edu.au/~nick MBDP M002 CRICOS Provider Code: 00126G e: Nick.Spadaccini@uwa.edu.au _______________________________________________ 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 (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (SIMON WESTRIP)
- References:
- Re: [ddlm-group] Relationship of CIF2 to legacy platforms (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Use of elides in strings
- Next by Date: Re: [ddlm-group] Use of elides in strings
- 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):