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

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

OK, we will need to edit up a modified version of the draft and put it on the IUCr site, as we can't attach documents to emails in the mailing list.  Stand by.

James.

On Tue, Jul 26, 2011 at 12:36 PM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote:
To avoid any misunderstanding and have us all working from the same base please send the proposal we are discussing as one self-contained document
 -- 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, 26 Jul 2011, James Hester wrote:

Dear DDLm-ers,

I agree that we should try and resolve any outstanding issues with CIF2 at the Madrid
meeting.  However, to make that approach workable we need to have exposed all the issues in
this forum so that we are not blindsided by new information in Madrid and left with no time
to process it.  I would therefore suggest that this discussion continues so that we can
identify precisely what the particular issues and alternatives are.  The less we have to
deal with in Madrid the more likely we will be able to converge on a solution.

So, to pursue Herbert's comments below:
(1) In what sense is John's draft an 'either-or' approach to prefixes and line folding? 
Doesn't it require both to be recognised?
(2) Are there any other reasons John's draft is not an improvement?

James.

On Wed, Jun 29, 2011 at 4:45 AM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote:
     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




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

Reply to: [list | sender only]