Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Relationship of CIF2 to legacy platforms

Title:
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



  


begin:vcard
fn:I.David Brown
n:Brown;I.David
org:McMaster University;Brockhouse Institute for Materials Research
adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada
email;internet:idbrown@mcmaster.ca
title:Professor Emeritus
tel;work:+905 525 9140 x 24710
tel;fax:+905 521 2773
version:2.1
end:vcard

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.