[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] String concatenation operator in CIF2. .
- To: Group finalising DDLm and associated dictionaries <email@example.com>
- Subject: Re: [ddlm-group] String concatenation operator in CIF2. .
- From: "Herbert J. Bernstein" <firstname.lastname@example.org>
- Date: Tue, 19 Oct 2010 07:17:01 -0400 (EDT)
- In-Reply-To: <AANLkTi=eH8bnhvEr5vJZJv+tV=cZiAYTTNCvjhTL8yzC@mail.gmail.com>
- References: <AANLkTimq3EvbmB7SSz1phMNxuLk7srvyF2eUPCB=n1YS@mail.gmail.com><email@example.com><AANLkTi=eH8bnhvEr5vJZJv+tV=cZiAYTTNCvjhTL8yzC@mail.gmail.com>
Dear James, Now we are down to matters of taste about alternate changes: an easy to implement but less powerful concatentation operator versus harder to implement but arbitrarily powerful incompletely specified new data types. In view of the past history of this group in rejecting even the existing imgCIF MIME-based binary data type, the rejection of the existing line-folding protocol, the two years needed to decide on which combinations of brackets we were going to use, and the amount of time to deal with the less troublesome encoding issues, to me it seems unwise to try to deal with a new data type right now to solve the very real problems of the lack of human readability of CIF2 in dealing with long strings (regexes, PDB sequences, etc). Now I do understand that some people, indeed most users, rarely or never read CIF dictionaries or mmCIF PDB entries "by eye," but some of us have to. The simple concatentation operator solves this very real problem for dictionary developers and those who might like to be able to manually read a PDB mmCIF entry. CIF is not a religion. It is a tool. I urge this group and will urge COMCIFS to be pragmatic and adopt Simon's underscore as a concatenation operator. I like it so much, that, unless sombody comes up with much better alternative or a truly practical reason why it is bad to do so, I will code it as an option on CBFlib and cif2cbf for my own use and use by any interested friends, so I can at least be able to read the files I have to work with. Don't worry, I won't call those files CIFs. I'll call them something else, but for my work I suspect I'll be using that format in preference to a purer dialect of CIF that does not support a concatentation operator. 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 firstname.lastname@example.org ===================================================== On Tue, 19 Oct 2010, James Hester wrote: > I agree that *if* we are to have a concatenation operator then a whitespace > delimited underscore appears to be the best choice. John B's email > contained a list of 8 objections to the *concept* of a concatenation > operator which I have reproduced below. I find the most substantial > objections to be (iv) and (v). Perhaps you would like to address these > particular objections? > > (James's list) > (i) added complexity > (ii) no longer a plain tag-value format (Nick's objection) > (iii) adding operators to data format files (not sure why this is exactly > bad) > (to which John B added:) > (iv) most or all of the perceived benefits can be realized without changing > CIF (by instead defining new or altered CIF data types) > (v) alternative solutions can support most of the proposed use cases even > better than a concatenation operator would > (vi) the impact of the proposed feature is not well understood (but is > probably greater than some here believe) > (vii) the proposed feature would constitute another incompatibility with > CIF1. > (viii) some of the benefits to be realized are fragile, in the sense that > they rely on formatting conventions that are not themselves part of CIF. > > On Tue, Oct 19, 2010 at 1:35 PM, Herbert J. Bernstein > <email@example.com> wrote: > Dear Colleagues, > > I may not have completely understood this discussion. To me > much > of the reasoning to be objecting to introducing the > concatenation operator because it changes the meaning of some > possible CIF files, not files that anybody has ever seen, but > possible ones. Simon's proposal of using the underscore really > does not conflict with any existing CIF because it cannot be > a data value (it begins with an underscore) but also cannot be > a tag name, because we have implicitly treated the underscore in > a tag name as a delimiter rather than part of the name and have > not accepted empty names. > > The only real remaining objection to the underscore seems to > be > that it does not look as nice as some of the more classical > concatenation operators: +, //, etc. While I would prefer one > of the classical operators, there really is nothing wrong with > the > underscore and it really does make it much easier to deal with > the transition to CIF2 both for regular expressions and for > folded lines. > > I ask for a formal vote by COMCIFS on the use of the > white-space > isolated underscore as a concatenation operator. To me it seems > to > be a very useful addition to CIF2 and at worst a harmless > addition. > > Regards, > Herbert > > > At 11:21 AM -0500 10/14/10, Bollinger, John C wrote: > >On Thursday, October 14, 2010 7:48 AM, James Hester wrote: > > > >>There are three separate issues: (1) do we want a string > concatenation > >>operator? (2) If so, what is the grammar for this operator (3) > what > >>character(s) will be used for this operator? > > > >[...] > > > >>Regarding the particular characters to use to represent > concatenation: > >>'+' is a poor choice given its possible uses as a datavalue in its > own > >>right, and I find that '_' is a little unintuitive and > unnecessarily > >>overloads underscore. Note that there is no reason to limit > ourselves > >>to a single character as we expect this operator to be used very > >>sparingly: we can use a digraph or trigraph if we so desire, > >>especially if it makes the meaning clearer to a naive user. > > > >If a concatenation operator is adopted, then I agree with Simon that > >it should be something that is not legal as a whitespace-delimited > >data value. (Ideally, not in CIF1, either.) I would prefer that it > >not be legal even as the leading character(s) of a > >whitespace-delimited data value. Without departing from the allowed > >ASCII characters, the lone underscore is the only viable string I > >see that meets all those criteria. > > > >I don't so much mind '//' as a concatenation operator, except that > >it must then be made a reserved word, and maybe even a reserved > >prefix. At least such a reservation is less likely to be a problem > >than reservation of '+' would be, but I don't see that choice as > >much more intuitive to the average user than '_'. > > > > > >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 > >firstname.lastname@example.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 > email@example.com > ===================================================== > _______________________________________________ > ddlm-group mailing list > firstname.lastname@example.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 email@example.com http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Re: [ddlm-group] String concatenation operator in CIF2. . (SIMON WESTRIP)
- [ddlm-group] String concatenation operator in CIF2 (James Hester)
- Re: [ddlm-group] String concatenation operator in CIF2. . (James Hester)
- Prev by Date: Re: [ddlm-group] String concatenation operator in CIF2. .
- Next by Date: Re: [ddlm-group] String concatenation operator in CIF2. .
- Prev by thread: Re: [ddlm-group] String concatenation operator in CIF2. .
- Next by thread: Re: [ddlm-group] String concatenation operator in CIF2. .