[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. .
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Mon, 25 Jul 2011 22:36:01 -0400 (EDT)
- In-Reply-To: <CAM+dB2c0YqY5awhy_DmV_HsQZVbXd5tWD5Qt4qKR3V5MnFMrXw@mail.gmail.com>
- References: <BANLkTi=KKXU7HCc7r2Xji0ssaJg+xkw9Jw@mail.gmail.com><8F77913624F7524AACD2A92EAF3BFA54299C88A2EA@11.stjude.org><alpine.BSF.2.00.1106281001210.95500@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54299C88A2EC@11.stjude.org><alpine.BSF.2.00.1106281436390.6872@epsilon.pair.com><CAM+dB2c0YqY5awhy_DmV_HsQZVbXd5tWD5Qt4qKR3V5MnFMrXw@mail.gmail.com>
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
Reply to: [list | sender only]
- Follow-Ups:
- References:
- [ddlm-group] The Grazulis eliding proposal: how to incorporate intoCIF? (James Hester)
- Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. . (Bollinger, John C)
- Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. . (Herbert J. Bernstein)
- Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. . (Bollinger, John C)
- Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. . (Herbert J. Bernstein)
- Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. . (James Hester)
- Prev by Date: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. .
- Next by Date: [ddlm-group] Simplifying string handling in CIF2
- Prev by thread: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. .
- Next by thread: Re: [ddlm-group] The Grazulis eliding proposal: how to incorporateinto CIF?. .. .
- Index(es):