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,

   I fear we are not comunicating very effectively.  I am
_not_ comfortable with the current state of the CIF2
document, and I do not find the current emendation to
be an improvement.  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.  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 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.

   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:

>
> On Tuesday, June 28, 2011 9:07 AM, Herbert J. Bernstein wrote:
>
> [...]
>
>>   For CIF2, I would urge that we try to make something
>> coherent and clear.  I don't think we are there yet.
>> Maybe, if time permits and enough of us are present,
>> we can converge on something in Madrid.
>
>
> No need to wait for Madrid.  Please find below a concrete realization of my most preferred alternative.  I think it's coherent and clear, though suggestions for improvement on that front are welcome.
>
>
> =====
>
> 1. In Change 6, section (3) of the CIF 2.0 syntax changes document:
>
> a) Before the sentence "CIF2 does not specify any interpretation of the contents of the string," insert: "The string is interpreted according to the CIF Line-Folding Protocol (Appendix 1) when its signature is present, and according to the CIF Text Prefix Protocol (Appendix 2) when its signature is present.  Otherwise, "
>
> b) Insert this text after "The string value is Sugar\nFlour\nButter, where \n is the literal newline sequence." as a new paragraph:
>
> When the Line-Folding Protocol and Text Prefix Protocol are applied to the same value, the value shall appear in CIF as if line-folding had been performed first, followed by prefixing.
>
>
> 2. Add a definition of the Line-Folding Protocol as Appendix 1 of the CIF 2.0 syntax changes document:
>
> Appendix 1.     The CIF Line-Folding Protocol
>
> The CIF line-folding protocol is a mechanism for splitting logical lines of text across two or more physical lines of a CIF semicolon-delimited data value ("text field").  A version of this protocol appears among the "Common Semantic Features" of CIF 1.1 and is in wide use in that context; in CIF 2.0 line-folding is part of the CIF syntax, as described below.
>
> The protocol applies to text fields whose contents (after interpretation of the text protocol, if applicable) begin with a backslash, followed by any number of whitespace characters other than newline, followed by newline or the end of the text field; that sequence is designated \<ws>*\n below.  There must not be any whitespace preceding the initial backslash.
>
> Given un-prefixed (Appendix 2) text field contents to which the line-folding protocol applies, the logical text it represents is derived from it by removing each occurrence of \<ws>*\n, including the initial one.  Different lines may have different amounts of whitespace between the trailing backslash and newline.
>
> Note that the line-folding protocol cannot elide the terminating \n; of a text field because the \n of that delimiter is not accounted part of the field contents.  It follows from the above definition of \<ws>*\n, however, that if the last line ends with \<ws>* then that will not appear in the unfolded value.
>
>
> 3. Add a definition of the of the Text Prefix Protocol as Appendix 2 of the CIF 2.0 syntax changes document:
>
> The CIF text-prefix protocol is a mechanism for formatting the logical content of a CIF semicolon-delimited value ("text field") so as to avoid misinterpretation of embedded appearances of \n;. It may also be useful for improving human readability of some CIFs.
>
> The protocol applies to text fields whose physical contents begin with a prefix (see below), followed by one or two backslashes, optionally followed by any amount of whitespace other than a newline, followed by a newline.  A prefix consists of a sequence of one or more characters that are permitted in a text field, except for backslash or newline, and does not begin with a semicolon.
>
> The second and all subsequent physical lines of the contents of a prefixed text field must begin with the designated prefix for that field.  The line containing the terminating semicolon is not part of the contents for this purpose.  The logical (i.e. "un-prefixed") contents of the field is derived from the physical contents by the following procedure:
>
> a) remove the prefix from each line, including the first
> b) if the first line starts with two backslashes then remove the first of them; otherwise remove the whole line
>
> Example 1:
>
> data_providing_example
> _example
> ;CIF>\
> CIF>data_example
> CIF>_text
> CIF>;This is an embedded multiline value
> CIF>;
> ; # here the field terminates.
>
> Example 2:
>
> data_providing_example
> _example
> ; \
> data_example
> _text
> ;This is an embedded multiline value
> ;
> ; # here the field terminates.
>
>
> =====
>
>
> 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
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 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.