[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF header
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] CIF header
- From: Nick Spadaccini <nick@csse.uwa.edu.au>
- Date: Mon, 23 Nov 2009 15:31:24 +0800
- Authentication-Results: postfix;
- In-Reply-To: <279aad2a0911222132v62448641r152a1199c3028b4f@mail.gmail.com>
Agree to #<something>CIF_2.0 <something> is whatever character sequence people are happy with. <something>=\# seems reasonable enough. Don't see we need for the _ between CIF and 2.0, but agnostic about it. I am assuming there must be an existing CIF_1.1 magic sequence in use - though I don't recall any formal specification for it. On 23/11/09 1:32 PM, "James Hester" <jamesrhester@gmail.com> 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 >> > > 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] CIF header (Herbert J. Bernstein)
- References:
- Re: [ddlm-group] CIF header (James Hester)
- Prev by Date: Re: [ddlm-group] CIF header
- Next by Date: Re: [ddlm-group] Use of elides in strings
- Prev by thread: Re: [ddlm-group] CIF header
- Next by thread: Re: [ddlm-group] CIF header
- Index(es):