Discussion List Archives

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

Re: [ddlm-group] CIF header

Title:
I agree with Brian's proposal (or some modification of this if it seems reasonable).

Does #\#CIF_1.2 refer to the macromolecular CIF or does it use the same standard at this level as the core?

David



James Hester wrote:
I agree with Brian's suggestion.  Can other participants also indicate
their agreement or alternative suggestions?

James.

On Fri, Nov 20, 2009 at 11:15 PM, Brian McMahon <bm@iucr.org> wrote:
Is there a reason why it can't be #!, to make it consistent with other *nix
based directives.
As James says, #! is normally understood by Unix shells to specify
an appropriate shell interpreter, not quite what we're aiming for here.

A characteristic initial set of bytes (file 'magic') is often used
by GUI file managers and other generic file-handling software to
associate icons or applications (in association with, or sometimes
competing against, the use of a filename extension). We use this
approach to identify the type of file uploaded in our submission
system. It's useful for that initial byte sequence to be (a) short
to facilitate rapid scanning, (b) specific to an individual file type.
For that reason we suggested for CIF 1.1 the magic string
     #\#CIF_1.1
For CBF it is
     ###CBF: VERSION

I recommend #\#CIF_2.0 to be consistent with version 1.1 and so that
generic file magic handling can map all #\#CIF_ strings to files of type
"cif". (A sophisticated file manager could extend the scan to allow for
different icons to be associated with version 1.1 and version 2 CIFs.)
It seems a pity from the viewpoint of neatness that the CIF and CBF
magic strings aren't more similar in structure.

Brian

On Fri, Nov 20, 2009 at 02:09:56PM +0800, Nick Spadaccini wrote:
We don't need an extra character, a single hash would suffice, but I guess
an extra character my uniquely identify it as the CIF header to a parser,
rather than it as just a comment. An extra character also moves you away
from an ordinary comment which is smart, to a smart comment which has its
own unique tag. I am NOT a fan of smart comments, or comments which can be
smart, but they seem to be to modus operandi of many systems.

On 20/11/09 1:59 PM, "James Hester" <jamesrhester@gmail.com> wrote:

Wouldn't this cause a UNIX-style OS to try to execute 'CIF2' if
someone accidentally typed the filename in a command context?  This is
not a huge problem in that it will otherwise attempt to execute
'data_xxxx', and only if the file is executable.

I guess I don't understand why we need an extra character after the
hash.  If we really do need an extra character, why not just another
hash?

On Mon, Nov 9, 2009 at 7:30 PM, Nick Spadaccini <nick@csse.uwa.edu.au> wrote:
On 30/10/09 11:47 PM, "Joe Krahn" <krahn@niehs.nih.gov> wrote:

A directive embedded in an initial comment really does make sense,
because it is irrelevant once the correct parser is selected. It might
make sense to add a specific 2nd character, similar to the POSIX shell
#!. For example, the STAR format could define an initial line beginning
with #% as parsing directive rather than just a plain comment. That
makes the abuse of a comment line as a bit less of a hack.
Is there a reason why it can't be #!, to make it consistent with other *nix
based directives.

cheers

Nick
_______________________________________________
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 Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council 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.