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

Re: [ddlm-group] CIF-2 changes

I am neutral on option 0 as long as we make a clear rule for both software
writers and users to follow.  Note that option 0 becomes moot as a 
practical matter if we restrict ourselves to just {}, but becomes a very
real issue once [] becomes a delimiter.

So so far the vote is:

   James and Herbert:  1 - 3 - 2 - 4
   James:  No on 0
   Herbert: Neutral on 0


=====================================================
  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, 10 Nov 2009, James Hester wrote:

> On Tue, Nov 10, 2009 at 2:30 AM, Herbert J. Bernstein
> <yaya@bernstein-plus-sons.com> wrote:
>> Dear Colleagues,
>>
>>   I am coping with the rapid ebb and flow of what delimiters will be
>> used for CIF2 by providing controls for both CIFtbx_4 and CBFlib_9
>> to turn on or off sensitivity to (), [] and {} delimiters separately,
>> so I can deal with whatever the final decision is by changing the
>> defaults, ...
>
> So I guess you have a proof of concept for whatever we decide on.
>
>>   BUT we really do have to settle this.  Ignoring the comma, quote and
>> colon issues, Since 2007 we have now gone through use of a of (), [], and
>> {} as reserved delimiters, use of just () and {}, and use of just {}.  It
>> is time to simply make a firm and final decision.
>
> To be fair, it is only since August this year that there has been any flux.
>
>>   We have dictionaries to write and code to implement.  I have already
>> delayed delivery of software to deal with this, and I really don't like
>> delaying delivery of software.
>>
>>   The use of the [] in CIF 1 dictionary category name is well-established.
>> I prefer to minimize the impact on handling existing dictionaries in a
>> CIF2 context and to stick strictly to {} as the only brackets in the
>> set of reserved delimiters and to allow both () and [] in non-delimited
>> strings and data names.  So let us have another straw vote:
>>
>>   Option 1:  {} will be reserved, but [] and () will not be reserved; or
>>   Option 2:  {} and [] will be reserved, but () will not be reserved; or
>>   Option 3:  {} and () will be reserved, but [] will not be reserved; or
>>   Option 4:  {}, () and [] will all be reserved
>>
>> I suggest preferences voting noting if any are fatal to anyone.
>>
>> My preferences are in decreasing order:  1 then 3 and 2 then 4, but, as
>> long as we settle this for once and for all, I can live with any of them.
>
> Unfortunately your options exclude allowing brackets both inside
> datanames/non-delimited strings and as list/table delimiters.  In
> light of Nick's email I suggest an additional formulation:
>
> 0. Make it possible to detect missing whitespace after datanames and
> non-delimited text strings if the following datavalue is a list or
> table? (Yes/No)
>
> If "Yes":  which of the above options do you prefer?
> If "No": which of the above options would you prefer if the majority
> prefer "Yes" as an answer to question 0?
>
> I vote "No" (don't make it possible to detect whitespace) and
> preferences same as Herbert (due to already existing square brackets
> in datanames).
>
>
> -- 
> 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
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]