Discussion List Archives

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

Re: [ddlm-group] String concatenation operator in CIF2. .

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 <yaya@bernstein-plus-sons.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
>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



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