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

Re: [ddlm-group] CIF-2 changes

Correct, if 1 is selected then 0 is moot.

I prefer {} and [] reserved AND no [] or punctuation in data names. I know
that is not being offered as an option, but I would still like to have the
question I posed previously answered.

Are we going make it impossible to cast data names into target code
identifiers by allowing embedded punctuation? I must say this would
completely cripple the existing dREL parser and require a significant
re-design and rethink. I suspect it will inhibit many people using scripting
languages to take dREL code and cast it in to running code.


On 10/11/09 8:29 PM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
wrote:

> 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

cheers

Nick

--------------------------------
Associate Professor N. Spadaccini, PhD
School of Computer Science & Software Engineering

The University of Western Australia    t: +61 (0)8 6488 3452
35 Stirling Highway                    f: +61 (0)8 6488 1089
CRAWLEY, Perth,  WA  6009 AUSTRALIA   w3: www.csse.uwa.edu.au/~nick
MBDP  M002

CRICOS Provider Code: 00126G

e: Nick.Spadaccini@uwa.edu.au




_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group


Reply to: [list | sender only]