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

[ddlm-group] CIF 1.5

(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.


 Herbert J. Bernstein, Professor of Computer Science
  Dowling College, Kramer Science Center, KSC 121
       Idle Hour Blvd, Oakdale, NY, 11769


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>
     Sorry something got lost in the prior message.  It should have

           Dear Colleagues,

            Back to the question of commas.  If you accept the desirability
           having a CIF 1.5, commas in lists become very useful.  Someone
           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


           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

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

Reply to: [list | sender only]