Discussion List Archives

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

Re: [ddlm-group] CIF 1.5

Dear James,

   Please look at the following part of your first paragraph:

"with a commitment to support CIF1.1 for the long term and a guaranteed 
way to distinguish the two types of data files."

and please look at the following part of your second paragraph

"Furthermore, they now have to support one more type of file going into 
the future."

I seem to be missing something.  If we are going to support CIF 1.1 for
the long term and we are going to have CIF 2 be a very different file 
type, then it is not CIF 1.5 that will cause software devlopers to have
to support one more file type going into the future, but the fundamental
decisions made by this group.

If you support CIF 1.1 and a very different CIF 2, then you are going to
end up with mixed files, i.e. multiple ad hoc CIF 1.5 (or actually CIF 
1.55) files.  All I am doing is proposing to formalize what is going to 
happen anyway.

   I've had my say.

   Regards,
     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 Tue, 1 Dec 2009, James Hester wrote:

> (Note to those reading this later: this continues a thread started within the 'space as
> list item separator' thread.  I recommend reading those messages before continuing on
> here).
> 
> (For those who came in late:
> We flirted with the idea of a minimally disruptive path from CIF1.1 to CIF2.0 back in the
> beginning of this group (late September/early October, I believe) , and ended up choosing
> to define one maximally disruptive CIF2.0 standard together with a commitment to support
> CIF1.1 for the long term and a guaranteed way to distinguish the two types of data files.)
> 
> Picking up the CIF1.5 discussion...
> Introducing CIF1.5 is a further source of confusion.  Apart from this, it produces extra
> workload for software authors.  Herb has essentially defined CIF1.5 as CIF1.1 plus new
> syntactical elements (or in other words CIF2.0 minus character set limitations and UTF8). 
> So in order to support CIF1.5, authors of both CIF reading and CIF writing software have
> to add this new syntax.  Then when they decide to support CIF2.0, they have to once again
> revisit their software.  I would have thought it far more sensible to ask them to update
> and distribute their software only once.  Furthermore, they now have to support one more
> type of file going into the future.
> 
> I see absolutely no benefit in this idea. 
> 
> On Tue, Dec 1, 2009 at 9:40 AM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote:
>       Dear James,
>
>        The point is that we will need to make it easy for people working with
>       CIF 1 and CIF 1.1 based tools to cobble together valid CIF 2 data.  The
>       most important bit will be a way to include vectors and matrices in their
>       data.  This will allow them to do it.
>
>        Please note that it hase taken several years to just get to the point
>       where we are beginning to rigorously define CIF 2.  If we are lucky, it
>       will only take a few years to have a full set of tools to allow users
>       and software writers to reliably produce true CIF 2 data.
>
>        Regards,
>          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 Tue, 1 Dec 2009, James Hester wrote:
>
>       Dear Herbert: as CIF 1.1 doesn't define lists, I'm not sure why you
>       suggest that the
>       example below is a valid tag.
>
>       On Tue, Dec 1, 2009 at 12:36 AM, Herbert J. Bernstein
>       <yaya@bernstein-plus-sons.com>
>       wrote:
>            Sorry something got lost in the prior message.  It should have
>            read:
>
>                  Dear Colleagues,
>
>                   Back to the question of commas.  If you accept the
>       desirability
>                  of
>                  having a CIF 1.5, commas in lists become very useful.
>        Someone
>                  with
>                  a CIF 1.1 editor will be able to prepare a CIF 1.5 file for
>       many
>                  useful cases by doing all lists with commas and no embedded
>       blanks
>                  as long as they can make their lists fit on single lines.  In
>       CIF
>                  1.1
>
>                  [[1,2,3],[4,5,6],[7,8,9]]
>
>                  is a valid value for a tag, but
>
>                  [[1 2 3] [4 5 6] [7 8 9]]
>
>       is not.
> 
>
>       No, neither example is a valid CIF 1.1 tag.  CIF 1.1 explicitly excludes
>       brackets as the
>       first character of a non-delimited string.
> 
>
>                  Having the option of commas in lists will help to smooth the
>                  transition for at least some people.
> 
> 
>
>       --
>       T +61 (02) 9717 9907
>       F +61 (02) 9717 3145
>       M +61 (04) 0249 4148
> 
> 
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
> 
> 
> 
> 
> --
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> 
>
_______________________________________________
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.

Useful links