Discussion List Archives

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

Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. .. .

Dear Colleagues,

Having slept on this, I have a proposal -- that we return string
handling as completely as possible to CIF1 conventions in supporting DDLm.

   Please recall the following from the original proposal on this
form of elide:

"5. If the prefixed text fields are implemented, arbitrary values can

be represented in CIFs at least as conveniently as can text fields in the
current CIF1.1 format. Thus, there is strictly speaking no need for the
"""/''' strings, and one could simplify CIF2.x by omitting them

altogether. However, the proposed method is orthogonal to the """/'''
string format, and thus both can be implemented simultaneously if

in other words, part of the proposal was to drop the treble quotes
entirely, i.e. to return at least in part to CIF1 string handling.

I suggest we complete the process and restore the CIF1 parse for all
quoted strings, i.e., that we _not_ terminate a quoted string scan for
the terminal quote on the first occurrence of the terminal quote,
but only on the first occurrence of the terminal quote followed by
white space.  The only place in DDLm where this causes a problem is
within bracketed constructs in the handling of the terminal bracket,
the comma or the colon immediately after a terminal quote mark or
in dealing with an unquoted string.    I propose that within the
bracketed constructs _only_ we terminate the scan for a closing quote
delimiter on the combination of the quote delimiter followed by any of:

     the closing bracket

This will preserve almost all existing CIFS (e.g. the ones with 'O''')
as valid, unchanged, and limit our parser changes for CIF2 primarily
to the handling of the new bracketed constructs and of this new elide
convention.  There is some small risk of invalidating existing CIFS
in adopting the new elide convention at the parser level rather than
at the semantic convention level, but, after sleeping on it, I agree
that that risk is minimal.


At 6:17 PM -0400 6/28/11, Herbert J. Bernstein wrote:
>Dear John,
>    There is nothing terribly wrong with any one aspect of the
>CIF2 document.  My problem is that for me it does not hang
>together as a coherent whole espcially on the issue of
>string representation.  Right now to me it is an uncomfortable
>mixture of CIF1 and Python string handling, and, as I have
>repeatedly stated, I would prefer to change to being entirely
>consistent with Python.  If that is not to be, I would prefer
>to go back to CIF1 string handling.  That is and has been my
>position for a very long time.
>    If something I have said in the past discussions is not clear,
>I will be happy to amplify, but right now I don't know what
>I can say that would not have me repeating myself.
>    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, 28 Jun 2011, Bollinger, John C wrote:
>>  Dear Herbert,
>>  On Tuesday, June 28, 2011 1:46 PM, Herbert J. Bernstein wrote:
>>>    I fear we are not comunicating very effectively.
>>  Evidently not.
>>>   I am
>>>  _not_ comfortable with the current state of the CIF2
>>>  document, and I do not find the current emendation to
>>>  be an improvement.
>>  Your opinions about the document and the proposed change are entirely at
>>  your discretion, of course, but it does come as a surprise to me that
>>  you think the entire changes document unsatisfactory.  If there are
>>  issues with it that you have not previously brought before the group
>  > then I would greatly appreciate the opportunity to hear and perhaps
>>  comment on them before Madrid.  Even those who will actually be present
>>  in Madrid might appreciate the opportunity to consider those issues
>>  ahead of time.
>>  As far as I am aware, the only point of CIF 2.0 syntax remaining open
>>  for discussion is the (in-)ability of CIF 2.0 to represent arbitrary
>>  strings.  Inasmuch as both this working group and COMCIFS already
>>  approved the changes document, I would be very reluctant to reopen it
>>  for general changes.  Nevertheless, if you have discovered serious flaws
>>  in it then better to fix them sooner than later.  Otherwise, it is
>>  unproductive to criticize proposals for being based on the only document
>>  available to base them on.
>>>   Much as I would dearly love to have
>>>  the current line-folding protocol in CIF2, I think it
>>>  is much more important to work on making CIF2 into
>>>  something clear and coherent.  I for one find the
>>>  either-or approach to prefixes and line-folding unnecessary
>>>  and confusing.
>>  Line folding and prefixes are compatible.  Saulius pointed this out in
>>  his initial description of the protocol, as a group we commented on it
>>  in our subsequent discussion, and my formal proposal from earlier today
>>  specifically and explicitly provides for them to work together.  I'm not
>>  sure how you acquired an impression to the contrary, but if it was from
>>  my text then please explain so that I can improve it.
>>>   When working with old fortran compilers,
>>>  I _need_ the line folding protocol.  If the prefixes
>>>  are bing introduced, I need a way to deal with both the
>>>  prefixes _and_ the line-folding protocol, not have it
>>>  be either-or.  I understand that mose people don't
>>>  see a problem, but I work with software both on new computers
>>>  and very, very old computers (e.g. I just brought an Indigo
>>>  back to life).
>>  I don't see a problem specific to line-folding and prefixes.  Not even
>>  for very old compilers.  I do appreciate that some old compilers present
>>  issues for text processing in general, and that these manifest in the
>>  context of CIF.  I think most of us do, else CIF 2.0 would be different.
>>>    I repeat my suggestion that we need to meet and talk things
>>>  out.  Maybe then I will understand what the rest of you are trying
>>>  to do, and maybe I will be able to explain what I am trying
>>>  to do.
>>  It was my understanding that there would indeed be opportunities for
>>  those who attend Madrid to meet, and I hope that at least one such
>>  meeting happens.  It will bear more fruit the better its participants
>>  can prepare for it, however.  If I were going to be present, then I
>>  would want to have as specific an idea as possible of the topics to be
>>  covered.  Bringing those up here, in advance, would have the added
>>  advantage of including, at least to some extent, group members who
>>  otherwise would be shut out.
>>  Regards,
>>  John
>>  --
>>  John C. Bollinger, Ph.D.
>>  Department of Structural Biology
>>  St. Jude Children's Research Hospital
>>  Email Disclaimer:  www.stjude.org/emaildisclaimer
>>  _______________________________________________
>>  ddlm-group mailing list
>>  ddlm-group@iucr.org
>>  http://scripts.iucr.org/mailman/listinfo/ddlm-group
>ddlm-group mailing list

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

ddlm-group mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

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