Re: [ddlm-group] Triple-quoted strings in light of latest CIF2 draft

Dear James,

  As noted previously and for the reasons stated, my vote on the draft as
it now stands will, with regret, be negative.

  Regards,
    Herbert

At 11:36 AM +1000 8/10/11, James Hester wrote:
>Dear Herbert and DDLm group,
>
>Thanks Herbert for this list.  Please be aware that I am hoping for
>a final draft to be voted on at, or soon following, the Madrid
>congress.  A final draft cannot logically allow for future
>incompatible changes.  As I see nothing in Herbert's list that has
>not been discussed already here, I will therefore press ahead with
>pursuing a final draft in time for Madrid on the assumption that
>this group was not, and will not, be able to reach agreement on the
>items below in finite time.
>
>On Wed, Aug 10, 2011 at 11:07 AM, Herbert J. Bernstein

><<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>wrote:
>
>Dear James,
>

>   I do not have a crystal ball, so all I can do is to guess at what
>what result from future discussions.  My best guesses are:
>
>   I believe the most likely incompatible change will be the adoption
>of the multi-line quoting mechanism from some version of Python.
>
>   The second most likely changes be in the handling of text fields to
>restore full compatibility with CIF 1.1 syntax, semantics and practice
>
>   The third most likely changes would be a harmonization of all the
>quoting mechanism to be closer to full Python practice with full use
>of the escape sequences.
>
>   The next area likely to introduce some small incompatibilities is
>a final version of the disambiguation signatures.
>
>   The next area likely to introduce incompatibilities is likely to be
>an extension of the current restrictive whitespace-delimited string
>to accept more of the CIF1 cases.
>
>   The next likely area to introduce incompatibilities would be a mechanism
>for support of CIF-1 style quoted strings in CIF2 documents.
>
>   The next likely area to introduce incompatibilities would be the addition
>of optional comma separators inside of bracketed constructs.
>
>etc.
>
>I don't think any of this involves problems for many data sets.  I also
>don't think CIF2 is likely to be stable for a few years, but I could
>be wrong and things may settle down quickly without any of the above
>happening.  We'll see what happens.
>
>   Regards,
>     Herbert
>
>
>
>
>
>At 9:43 AM +1000 8/10/11, James Hester wrote:
>>Dear Herbert - For this draft to be a useable document, we must
>>strictly limit the scope of any possible incompatible revisions.
>>Could you please therefore list what particular further revisions
>>you have in mind so that we can assess how significant these might
>>be.
>>
>>We should be very close to a final draft so any, even minor,
>>incompatible changes must be dealt with ASAP.
>>
>>On Tue, Aug 9, 2011 at 7:48 PM, Herbert J. Bernstein
>

>  ><<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>>wrote:
>>
>

>  >Dear James,
>>
>>   We see things very differently.  I find it difficult to understand
>>the interactions of a syntax document with pieces in isolation and
>>divorced from semantics.  Others may or may not have a similar view.
>>I am just one person.
>>
>>I find John's next iteration very useful.  It makes it clear that
>>I have failed clearly to express my concerns on the handling of the
>>text field final newline and it does not speak
>>to the status of the common semantic features document in a CIF2
>>context, so my vote on this proposal is negative.  As I said, I
>>am just one person, but that is my opinion.  I believe that, while
>>the combination of CIF 1.1, DDLm, dREL and the new dictionaries
>>with be very useful and is ready for use, that this version of CIF 2
>>is not quite ready for use in user data files, yet.
>>
>>However, I would not wish to delay getting to that point, so what
>  >I would suggest it that this draft be put into use with the warning
>>that it is subject to possible further small, but possibly
>>incompatible revisions.
>>
>>Regards,
>>   Herbert
>>
>>=====================================================
>>   Herbert J. Bernstein, Professor of Computer Science
>>    Dowling College, Kramer Science Center, KSC 121
>>         Idle Hour Blvd, Oakdale, NY, 11769
>>
>
>  >

><tel:%2B1-631-244-3035><tel:%2B1-631-244-3035>+1-631-244-3035
>>
>><mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu
>>=====================================================
>>
>

>  >On Tue, 9 Aug 2011, James Hester wrote:
>>
>>Dear Herbert:  I think it is an unreasonable imposition on busy people to
>>require them to constantly edit and repost a complete draft document with no
>>guarantee that their work will have moved the discussion forward,
>>particularly when the proposed changes have been adequately described by
>>email.  John has nevertheless kindly provided an updated draft (attached,
>>hopefully the attachment works).
>>
>>In future, I strongly suggest we proceed as follows:
>>(1) we first conditionally agree or disagree or request clarification of
>>proposed amendments;
>>(2) after any further refinements, those amendments are put into the syntax
>>draft in the expectation that only technical changes will be necessary;
>>(3) we all have a final chance to check that we are satisfied with this
>>final draft.
>>
>>I will address your comments on 'numb' type in the appropriate thread.
>>
>>I specifically did not propose reserving the various letter prefixes and I'm
>>glad that you have clarified your position.  Given that we have already had
>>extensive discussion around triple quoted string semantics, the most
>>appropriate course to follow now would be to vote on how much of the python
>>triple-quoted string space to reserve.  I think that vote will need to wait
>>until we have agreement on the current amendments.
>>
>>
>>On Tue, Aug 9, 2011 at 1:51 AM, Herbert J. Bernstein
>

>  ><<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>wrote:
>

>  >      Dear James,
>>
>>         I don't explicitly agree or disagree with John B's proposed
>>       amendments, because I have not seem them in the context of a
>>       completed document.
>>       Especially in a pure syntax document isolated from semantics,
>>       "God and
>>       the Devil are in the details," i.e. in the precise form of the
>>       interactions among the productions of the language.  John's
>>       latest
>>       message did not adopt
>>       my examples and clarifications, but promised some unspecified
>>       other
>>       examples, "Yesterday I wrote an example for combining the two
>>       protocols, and I can easily write one or two for the
>>       line-folding
>>       protocol on its own."
>>       John, himself seem uncomfortable with my clarifications.  Nobody
>>       other than
>>       you has even accepted the interpretations of the text field
>>       termination.
>>       I look forward to a revised proposal bringing together what has
>>       been
>>       discussed thus far and we can all consider if it does or does
>>       not express
>>       an acceptable set of revisions to the existing CIF 1.1
>>       specification.
>>
>>       [edit]
>>
>>
>>         Most interestingly -- while I proposed a specific reservation
>>       for the
>>       Python 2.7 treble quote syntax, you have proposed  a reservation
>>       for
>>       "all strings commencing with triple double quotes or triple
>>       quotes,"
>>       which excludes the necessary reservations for the python style
>>       elides
>>       which impact when a string terminates and excludes the r""",
>>       b""", u"""
>>       treble quote initiators.  I propose the following explicit
>>       wording
>>       be in the CIF2 document:
>>
>>         Means of extending the string quoting mechanisms in CIF are
>>       under
>>       consideration.  Strings conforming to the Python 2.7 triple
>>       quote
>>       syntax as specified in section 2.4.1 of
>>
>
>  >

><<http://docs.python.org/reference/lexical_analysis.html>http://docs.python.org/reference/lexical_analysis.html><http://docs.python.org/reference/lexical_analysis.html>http://docs.python.org/reference/lexical_analysis.html

>
>  >and
>>       strings conforming to the Python 3.2 syntax as specified in
>>       section
>>       2.4.1 of
>>
>
>  >

><<http://docs.python.org/py3k/reference/lexical_analysis.html>http://docs.python.org/py3k/reference/lexical_analysis.html><http://docs.python.org/py3k/reference/lexical_analysis.html>http://docs.python.org/py3k/reference/lexical_analysis.html

>
>  >      are reserved for future use and should not be used for any
>>       purpose
>>       that conflicts with the Python 2.7 or 3.2 interpretation in a
>>       CIF 2
>>       document.  In particular, string literals beginning with ''' or
>>       """
>>       with or without any of the prefixes r, R, u, U, b, B or the
>>       various
>>       combinations of prefixes allowed in python should not be used
>>       with
>>       a meaning that conflicts with the python interpretation.
>>
>>       While I personally prefer immediate adoption of the Python 2.7
>>       flavor
>>       of treble quotes, this wording leaves all options from
>>       non-adoption
>>       to full adoption of 2.7 or 3.2 on the table.
>>
>>         Regards,
>>           Herbert
>>
>>
>>       At 2:10 PM +1000 8/8/11, James Hester wrote:
>>>Dear Herbert: you have not explicitly stated that you agree with
>>>John B's proposed amendments, and so naturally no updated draft has
>>>been produced.  The latest comment on this issue was from John B and
>>   >I have seen no reply to that.  Therefore, please indicate all those
>>>amendments that John B. has proposed that you are satisfied with so
>>>that they can be incorporated into the document.
>>>
>>>As you have in the past argued for the inseparability of syntax and
>>>semantics, I have raised the various issues around 'numb' type and
>>>indeed the internal semantics of strings in order to make sure that
>>>they are addressed in a joint fashion.  As a result of recent
>>>discussions here, my belief is that there are no changes necessary
>>>to CIF1.1 common semantics except:
>>>(i) the issues around line folding protocol and Grazulis protocol
>>>that we are currently discussing
>>>(ii) clarification of the meaning of 'numb' type.
>>>
>>>I was suggesting that we reserve all strings commencing with triple
>>>double quotes or triple quotes.  How does this differ from your
>>>proposal below?
>>>
>>>On Mon, Aug 8, 2011 at 1:26 PM, Herbert J. Bernstein
>

>  >><<mailto:<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>

>
>  >>wrote:
>>>
>>>Dear Colleagues,
>>>
>>>     I have not seen an updated draft in response to my comments.  Have
>>>I missed something?  The last draft I see on the IUCr web site is
>>>the one from 27 July, and that document does not include any of the
>>>clarifications and comments that were in John's emails, especially
>>his
>>>email of 2 August.
>>>
>>>     In addition, we have a sharp disagreement on the issue of syntax
>>>without semantics.  While I would prefer to have syntax and semantics
>>>dealt with as a whole, at the very least we need to clarify the
>>status
>>>of the existing common semantics features document in the context
>>>of CIF2.  Do all features remain valid or are some deprecated or are
>>>CIF2 semantics something for some future effort?
>>>
>>>     If we are "to reserve triple-quoted strings for future expansion"
>>then
>>>we need to be specific about what we are reserving.  I would propose
>>>reserving all sequences conforming to all the python 2.7 treble quote
>>>lexing rules for future expansion.
>>>
>>>      My vote on the 27 July document without further clarification
>>will,
>>>with regret, have to be negative.  While I am a strong proponent of
>>>moving forward with dREL, DDLm and the new dictionaries, I believe
>>>that the combination of CIF 1.1, dREL, DDLm and the new dictionaries
>  >>would better serve the community at this time than would use of CIF 2
>>>as currently specified, except to the minimal extent needed to
>>>write the dictionaries.  That way all current CIF data sets and most
>>>CIF software will remain valid and people can continue to work as
>>they
>>>are working until a complete new specification with supporting
>>software
>>>is ready for them.
>>>
>>>     Regards,
>>>       Herbert
>>>
>>>P.S.  While writing this message, James' message that says:
>>>
>>>At 1:10 PM +1000 8/8/11, James Hester wrote:
>>>>I am not proposing a change to CIF1.1 behaviour, as I have stated
>>>>before, so any 'asking for trouble' is purely CIF1.1 asking for
>>>>trouble.
>>>>
>>>>The cif2cif example has focused my thinking. Given that I am not
>>>>actually proposing anything new, there are no consequences for such
>>>>programs in clarifying that CIF1.1 'numb' datavalues have a dual
>>>>'number'/'char' datatype.
>>>
>>>I do not understand how this addresses the design of a rule of 19 to
>>>rule of 9 converter such as cif2cif, nor do I understand how this
>>>addresses the handling of ISSNs and page ranges without a dictionary
>>>to say the values involved are ISSNs and page ranges.  I would
>>suggest
>>>this issue be on the closed meeting agenda.  Perhaps we can find
>>>some mutual agreement. -- HJB
>>>
>>>
>>>At 12:26 PM +1000 8/8/11, James Hester wrote:
>>>>As I understand it, the current position of this group on the latest
>>>>draft, incorporating Saulius's suggestions, is generally positive.
>>>>Herbert has raised some technical concerns, which I believe that
>>>>John B. has answered more than adequately.  If any concerns remain
>>>>among any members of this group, please advise as to what they are
>>>>and (if relevant) how the draft should be changed to address them.
>>>>
>>>>The related discussion topic was waiting for the latest draft was
>>   >>the fate of triple-quoted strings.  Assuming that the latest CIF2
>>>>syntax draft is accepted, and given the lack of agreement on
>>>>triple-quoted string syntax and semantics, should we simply drop
>>>>triple-quoted strings from the CIF2 syntax, possibly reserving
>>>>triple quotes for future expansion?  I would appreciate anybody with
>>>>an opinion on this contributing now so that we can have a hope of
>>>>wrapping it up before or during Madrid.
>>>>
>>>>
>>>>
>>>>On Wed, Aug 3, 2011 at 11:52 AM, Herbert J. Bernstein
>>>
>

>  >> ><<mailto:<mailto:<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:<mailto:yaya@bernstein-plus-sons.co>yaya@bernstein-plus-sons.co><mailto:yaya@bernstein-plus-sons.co>yaya@bernstein-plus-sons.co
>>m><mailto:<mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>

>
>  >>
>>>    >wrote:
>>>>
>>>>     > I take it, then, that you do not find the Sugar\nFlour\nButter
>>example
>>>    >>  in the current draft to be sufficient for this purpose.  Fair
>>enough,
>>>>>     but that leaves me uncertain of what kind of clarification you
>>are
>>>>     > looking for.  Perhaps you would be willing to suggest something
>>>>>     specific?
>>>>>
>>>>
>>>>I would suggest a clear statement of the intended meaning for
>>>>
>>>>;abcd
>>>>;
>>>>
>>>>;\
>>>>ab\
>>>>cd
>>>>;
>>>>
>>>>;\
>>>>ab\
>>>>cd\
>>>>;
>>>>
>>>>;CIF>\\
>>>>CIF>ab\
>>>>CIF>cd
>>>>;
>>>>
>>>>The combination of the current draft and your email leads me to
>>>>suspect that all of these may be intended to be equivalent
>>>>to "abcd" and to 'abcd' and to a blank delimited abcd
>>>>
>>>>Is that correct?  If not, please disambiguate as appropriate.
>>>>
>>>>
>>>>>     If it would help, I would be happy to add a brief clarifying
>>remark to
>>>>>     Change 11 that summarizes the status of comment line folding in
>>CIF2.
>>>>>     For example: "Although CIF 1.1's common semantic features
>>include an
>>>>>     analogous line-folding protocol for comments, that protocol is
>>not
>>>>>     incorporated into CIF 2.0 _syntax_.  Although it remains outside
>  >the
>>>>>     scope of CIF syntax, it is anticipated that some CIF 2.0
>>processors will
>>>>>     continue to recognize that protocol."
>>>>
>>>>I understand neither your analysis nor your suggested wording.
>>>>You seem to be arguing issues not in dispute.
>>>>How about the following?
>>>>
>>>>"The analagous line-folding protocol for comments specified in
>>>>paragraph 26 of the common semantic features of CIF 1.1
>>>>remains a common semantic feature of CIF 2.  There is no
>>>>change in comment syntax between CIF 1.1 and CIF2."
>>>>
>>>>
>>>>>     That is a question of application design, not CIF syntax.  It is
>>>>>     perilous to write files using that formalism, as some CIF
>>processors
>>>>>     would certainly reject them, but that's outside the scope of the
>>spec.
>>>>>     The spec merely defines that such files are not well-formed
>>CIFs.  As
>>>>>     for reading files that use it, I adapt an old saw from the
>>Fortran
>>>>>     community: if the file does not comply with the CIF
>>specifications then
>>>>>     a processor may do anything it wants with it, including starting
>>World
>>>>>     War III.  I do trust that most CIF readers will exercise greater
>>>>>     restraint, however.
>>>>
>>>>This is a technically defensible but impractical position.
>>>>Some syntax errors make it impossible to guess the intent
>>>>of the text.  Some syntax errors have a clear intent.
>>>>Most syntax errors are in some fuzzy middle ground.
>>>>The normal practice is extending languages is to try
>>>>to add new constructs somewhere in the middle ground
>>>>of syntax errors with clear intent or at the boundary.
>>>>It is in large part becuase of the espousal of a similar
>>>>position to yours by X3J3 that I have a supply of
>>>>bumper stickers that say "Save Fortran -- Ban X3J3"
>>>>The community voted with its feet (and programs) and
>>>>the current Fortran practice is for compilers to
>>>>compile almost everything that looks like a reasonable
>>>>variant of Fortran-77, Fortran-8x, Fortran-9x and Fortran-2003
>>>>with a minimum of fuss.  I was just compiling a Fortran-77
>>>>program with the latest gfortran and it accepted the program
>>>>happily and without a single warning (even though I
>>>>used -Wall).  I use the same compiler to handle rather
>>   >>recent Fprtran-2003 code including code with the new ISO
>>>>C binding to allow mixed C and Fortran.  I think the
>>>>current approach to be a much better way to design
>>>>processing software than the old X3J3 approach of the
>>>>1980 and early 1990s that kept breaking old programs.
>>>>
>>>>=====================================================
>>>>     Herbert J. Bernstein, Professor of Computer Science
>>>>       Dowling College, Kramer Science Center, KSC 121
>>>>            Idle Hour Blvd, Oakdale, NY, 11769
>>>>
>>>
>>>    >
>>>
>

>  >><tel:%2B1-631-244-3035><tel:%2B1-631-244-3035><tel:%2B1-631-244-3035><tel:%2B1-631-244-3035>+1-631-244-3035
>>>>
>>>><mailto:<mailto:<mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:<mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu>

>
>  ><mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu
>>>
>>>    >=====================================================
>>>>
>>>>On Tue, 2 Aug 2011, Bollinger, John C wrote:
>>>>
>>>>>     Dear Herbert,
>>>>>
>>>>>     On Monday, August 01, 2011 5:48 PM, you wrote:
>>>>>
>>>>>>     The present change document is unclear about the non-inclusion
>>of the
>>>>>>     terminal linefeed in all text fields.
>>>>>
>>>>>
>>>>>     I take it, then, that you do not find the Sugar\nFlour\nButter
>>example
>>>    >>  in the current draft to be sufficient for this purpose.  Fair
>>enough,
>>>>>     but that leaves me uncertain of what kind of clarification you
>>are
>>>>>     looking for.  Perhaps you would be willing to suggest something
>>>>>     specific?
>>>>>
>>>>>     [...]
>>>>>
>>>>>
>>>>>>     If the comment side of the original line-folding protocol is
>>>>     >> acceptable, the change document should say so.  Otherwise, by
>  >>>>>    explicitly including the text field part of paragraph 26, but
>>>>>>     not the comment part, the impression might be created that
>>>>>>     the comment line folding is excluded from CIF2.
>>>>>
>>>>>
>>>>>     Comment folding is acceptable, _and_ it is excluded *from
>>>>>     standardization* into CIF *syntax*.  These are compatible
>>because 1)
>>>>>     Folding and unfolding comments does not change the syntactic
>>validity of
>>>>>     CIFs 2) Comments have no meaning to CIF, other than constituting
>>>>>     whitespace, so folded and unfolded forms are syntactically,
>>>>>     grammatically, and even semantically equivalent from a CIF
>>perspective.
>>>>>
>>>>>     Other kinds of comment transformation are in the same class, and
>>are
>>>>>     equally acceptable and equally non-standardized.  For example,
>>one could
>>>>>     imagine transforming CIF comments by adding, removing, or
>>regularizing
>>>>>     whitespace between the comment start character and the first
>>printable
>>>>>     character.
>>>>>
>>>>>     The CIF syntax specifications do not require any particular
>>handling of
>>>>>     comments beyond treating them as whitespace.  Processors aren't
>>required
>>>>>     even to retain them or pass them on to an application, though
>>they are
>>>>>     certainly permitted to do so.  Likewise, they are permitted
>>perform any
>>>>>     transformation they wish on comment bodies.  There is no
>>advantage in
>>>>>     choosing any one particular transformation to promote from a
>>"may" to a
>>>>>     "must".
>>>>>
>>>>>     Text field prefixing provides a good contrast.  It must be
>>included in
>>>>>     the syntax if we want it, because it imposes additional syntax
>>>>>     requirements on text fields (either their bodies must not start
>>with a
>>>>>     prefix or every line must be prefixed as specified by the
>>protocol).
>>>>>
>>>>>     Text field line folding is in the middle.  It doesn't impose any
>>>>>     additional syntactic constraints, but its inclusion would be
>>justified
>>>>>     by its role in ensuring that CIF syntax is capable of expressing
>>>>>     arbitrary string values.  There is no analogous general mandate
>>for CIF
>>>>>     comments.
>>>>>
>>>>>     If it would help, I would be happy to add a brief clarifying
>>remark to
>>>>>     Change 11 that summarizes the status of comment line folding in
>>CIF2.
>>>>>     For example: "Although CIF 1.1's common semantic features
>>include an
>>>>>     analogous line-folding protocol for comments, that protocol is
>>not
>>>>>     incorporated into CIF 2.0 _syntax_.  Although it remains outside
>>the
>>>>>     scope of CIF syntax, it is anticipated that some CIF 2.0
>>processors will
>>>>>     continue to recognize that protocol."
>>>>>
>>>>>
>>>>>>     The question on a terminal ;\ was not whether is it
>>syntactically
>>>>>>     correct under the current CIF2 document, but what the document
>>>>>>     expects us to do about it.
>>>>>
>>>>>
>>>>>     The CIF syntax specification does not answer that question.  CIF
>>syntax
>>>>>     places no particular expectations on what processors should do
>>with
>>>>>     input that fails to be well-formed CIF.  Indeed, it places very
>>few
>>>>>     expectations even on what they should do with input that *is*
>>>>>     well-formed CIF.
>>>>>
>>>>>
>>>>>>      It comes up because in existing
>>>>>>     validation suites for the line-folding protocol under CIF1,
>>rather
>>>>>>     than treating as an error, it uses it as a way to allow an
>>>>>>     embedded \n; in a line-folded text field.  Inasmuch as we are
>>>>>>     in agreement that \n;\ is not a syntactically valid termination
>>>>>>     of a text field in CIF2 as defined in the change document,
>>there
>>>>>>     is no harm in those of us who use the construct under as a
>>>>>>     non-conflicting extension to CIF1 to continue to do so under
>>CIF2.
>>>>>
>>>>>
>>>>>     That is a question of application design, not CIF syntax.  It is
>>>>>     perilous to write files using that formalism, as some CIF
>>processors
>>>>>     would certainly reject them, but that's outside the scope of the
>>spec.
>>>    >>  The spec merely defines that such files are not well-formed
>>CIFs.  As
>>>>>     for reading files that use it, I adapt an old saw from the
>  >Fortran
>>>>>     community: if the file does not comply with the CIF
>>specifications then
>>>>>     a processor may do anything it wants with it, including starting
>>World
>>>>>     War III.  I do trust that most CIF readers will exercise greater
>>>>>     restraint, however.
>>>>>
>>>>>
>>>>>     Regards,
>>>>>
>>>>>     John
>>>>>
>>>>>     --
>>>>>     John C. Bollinger, Ph.D.
>>>>>     Department of Structural Biology
>>>>     > St. Jude Children's Research Hospital
>>>>>
>>>>>
>>>>>     Email Disclaimer:
>>>
>>>    >>
>

>  >><<<<http://www.stjude.org/emaildisclaimer>http://www.stjude.org/emaildisclaimer><http://www.stjude.org/emaildisclaimer>http://www.stjude.org/emaildisclaimer><<http://www.stjude.org/emaildisclai>http://www.stjude.org/emaildisclai><http://www.stjude.org/emaildisclai>http://www.stjude.org/emaildisclai
>>mer><<<http://www.stjude.org/emaildisclaimer>http://www.stjude.org/emaildisclaimer><http://www.stjude.org/emaildisclaimer>http://www.stjude.org/emaildisclaimer><<http://www.stjude.org/emaildisclaimer>http://www.stjude.org/emaildisclaimer><http://www.stjude.org/emaildisclaimer>www.stjude.org/emaildisclaimer
>>>>>
>>>>>     _______________________________________________
>>>>>     ddlm-group mailing list
>>>>>
>>>>><mailto:<mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:<mailto:ddlm-group@>ddlm-group@>ddlm-group@
>><<http://iucr.org>http://iucr.org><http://iucr.org>iucr.org><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>>>
>>>>><<<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://scripts.iuc>http://scripts.iuc><http://scripts.iuc>http://scripts.iuc
>><<http://r.org/mailman/listinfo/ddlm-group>http://r.org/mailman/listinfo/ddlm-group><http://r.org/mailman/listinfo/ddlm-group>r.org/mailman/listinfo/ddlm-group><<<http://scripts.iucr.org/mailman/listinfo>http://scripts.iucr.org/mailman/listinfo><http://scripts.iucr.org/mailman/listinfo>http://scripts.iucr.org/mailman/listinfo
>
>  >/ddlm-group><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>>>
>
>  >>>_______________________________________________
>>>>ddlm-group mailing list
>>>><mailto:<mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:<mailto:ddlm-grou>ddlm-grou>ddlm-grou
>><mailto:<mailto:p@iucr.org>p@iucr.org><mailto:p@iucr.org>p@iucr.org><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>><<<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://scripts.iucr>http://scripts.iucr><http://scripts.iucr>http://scripts.iucr
>>.org/mailman/listinfo/ddlm-group><<<http://scripts.iucr.org/mailman/listinfo/>http://scripts.iucr.org/mailman/listinfo/><http://scripts.iucr.org/mailman/listinfo/>http://scripts.iucr.org/mailman/listinfo/
>
>  >ddlm-group><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group

>>>
>>>    >
>>>>
>>>>
>>>>
>>>>--
>>>>T
>
>  >>><tel:%2B61%20%2802%29%209717%209907><tel:%2B61%20%2802%29%209717%209907>+61
>>>>(02) 9717 9907
>>>>F
>>>><tel:%2B61%20%2802%29%209717%203145><tel:%2B61%20%2802%29%209717%203145>+61
>>>>(02) 9717 3145
>>>>M
>>>><tel:%2B61%20%2804%29%200249%204148><tel:%2B61%20%2804%29%200249%204148>+61
>
>  >>>(04) 0249 4148
>>>>
>>>
>>>    >_______________________________________________
>>>>ddlm-group mailing list
>

>  >>><mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>
>  >
> >><<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://scripts.iucr>http://scripts.iucr><http://scripts.iucr>http://scripts.iucr.

>
>  >org/mailman/listinfo/ddlm-group
>>>
>>>--
>>>
>>>=====================================================
>>>    Herbert J. Bernstein, Professor of Computer Science
>>>      Dowling College, Kramer Science Center, KSC 121
>>>           Idle Hour Blvd, Oakdale, NY, 11769
>>>
>>>
>
>  >>

><tel:%2B1-631-244-3035><tel:%2B1-631-244-3035><tel:%2B1-631-244-3035>+1-631-244-3035
>>>
>>>
>>><mailto:<mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu
>>>=====================================================
>>>
>

>  >>_______________________________________________
>>>ddlm-group mailing list
>>><mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>
>  >><<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://scripts.iucr.o>http://scripts.iucr.o><http://scripts.iucr.o>http://scripts.iucr.o

>
>  >rg/mailman/listinfo/ddlm-group
>>>
>>>
>>>
>>>
>>>--
>>>T

>>><tel:%2B61%20%2802%29%209717%209907><tel:%2B61%20%2802%29%209717%209907>+61
>>>(02) 9717 9907
>>>F
>>><tel:%2B61%20%2802%29%209717%203145><tel:%2B61%20%2802%29%209717%203145>+61
>>>(02) 9717 3145
>>>M
>>><tel:%2B61%20%2804%29%200249%204148><tel:%2B61%20%2804%29%200249%204148>+61
>>>(04) 0249 4148
>>>
>>>_______________________________________________
>>>ddlm-group mailing list
>>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org

>>><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group

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

>> <tel:%2B1-631-244-3035><tel:%2B1-631-244-3035>+1-631-244-3035
>>
>> <mailto:<mailto:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.edu>yaya@dowling.edu
>>=====================================================
>>_______________________________________________
>>ddlm-group mailing list
>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>

>  ><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group

>
>  >
>>
>>
>>
>>--
>>T
>><tel:%2B61%20%2802%29%209717%209907><tel:%2B61%20%2802%29%209717%209907>+61
>>(02) 9717 9907
>>F
>><tel:%2B61%20%2802%29%209717%203145><tel:%2B61%20%2802%29%209717%203145>+61
>>(02) 9717 3145
>>M
>><tel:%2B61%20%2804%29%200249%204148><tel:%2B61%20%2804%29%200249%204148>+61
>>(04) 0249 4148
>>
>>
>>_______________________________________________
>>ddlm-group mailing list
>><mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org

>><<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group

>  >
>>
>>
>>
>>--
>
>  >T <tel:%2B61%20%2802%29%209717%209907>+61 (02) 9717 9907
>>F <tel:%2B61%20%2802%29%209717%203145>+61 (02) 9717 3145
>>M <tel:%2B61%20%2804%29%200249%204148>+61 (04) 0249 4148
>>
>>_______________________________________________
>>ddlm-group mailing list
>><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
>
>--
>=====================================================
>  Herbert J. Bernstein, Professor of Computer Science
>    Dowling College, Kramer Science Center, KSC 121
>         Idle Hour Blvd, Oakdale, NY, 11769
>
>                  <tel:%2B1-631-244-3035>+1-631-244-3035
>                  <mailto:yaya@dowling.edu>yaya@dowling.edu
>=====================================================
>_______________________________________________
>ddlm-group mailing list
><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
><http://scripts.iucr.org/mailman/listinfo/ddlm-group>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


--
=====================================================
 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
=====================================================
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group