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