[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
File identifier (was Re: Seattle Discussions)
- To: Multiple recipients of list <imgcif-l@bnl.gov>
- Subject: File identifier (was Re: Seattle Discussions)
- From: Peter Keller <bsspak@bath.ac.uk>
- Date: Thu, 19 Sep 1996 05:31:11 -0400 (EDT)
On Wed, 18 Sep 1996, Andy Hammersley wrote: > > Concerning my point 3. > > Thanks to Peter Keller for precision on his suggestion for the > file identifier. > > >From Peter: > > > My suggestion was to define a particular format of data block header, > > maybe something like: > > > > data_image0001(type=CBF_v1.0) > > etc. > > The main point is for the file identifier to be standard for all > cbf files, so easy to parse for system utilities and programs alike; the > version number is a secondary issue. > > Could this idea be sensibly re-ordered to make more of the initial > bytes invariant ? e.g. > > data_cbf_image0001 > > where the 'data_cbf_' (or similar characters) are ALWAYS the first 9 > characters of a CBF. My understanding is that IUCr/COMCIFS approval would be necessary to reserve something like this for CBF use (i.e. disallow the use of data block headers beginning 'data_cbf_' for other purposes. (Perhaps David could comment on this, or correct me if I am wrong?) There is no technical reason why it could not be done this way, as far as I can see. > Some formats use "{" and "}" to delimit the header. This has a certain > elegance. > > e.g. Changing slightly the above suggestion there could be matched pair > like: > > data_cbf_begin_image0001 > > .. > > data_cbf_end_image0001 > > This would fulfill my "matched pair" requirement, but perhaps causing > problems, in that 'data_*' is a standard CIF method for introducing > a data block. We could of course filter out the > 'data_cbf_end_image0001' before writing to a CIF, but maybe someone > has better/ alternative ideas ? >From the point of view of STAR/CIF, this would imply a second, empty, data block. In the STAR syntax as published in JCICS, empty data blocks are not allowed. In more recent (uncirculated) discussions between myself, Brian McMahon and Nick Spadaccini, we have agreed that there is, in fact, nothing wrong with an empty data block, so doing it this way should work. I hope that I will be in a position to circulate the results of these discussions on the STAR syntax soon, but there are still a couple of issues to be resolved. Regards, Peter. ======================================================================== Peter Keller. \ Dept. of Biology and \ "...nothing works, but Biochemistry, \ everything survives...." University of Bath, \ Bath, BA2 7AY, UK. \ --- Carlos Fuentes ------------------------------\----------------------------------------- Tel. (+44/0)1225 826826 x 4302 | Email: P.A.Keller@bath.ac.uk (Internet) Fax. (+44/0)1225 826779 | P.A.Keller%bath.ac.uk@UKACRL (BITNET) ========================================================================
Reply to: [list | sender only]
- Prev by Date: Re: Seattle Discussions
- Next by Date: Re: File identifier (was Re: Seattle Discussions)
- Prev by thread: Re: area detector cif definitions
- Next by thread: Re: File identifier (was Re: Seattle Discussions)
- Index(es):