[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] CIF-2 changes
- To: Nick.Spadaccini@uwa.edu.au, Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] CIF-2 changes
- From: James Hester <jamesrhester@gmail.com>
- Date: Wed, 11 Nov 2009 17:28:14 +1100
- In-Reply-To: <C71F83C7.123CE%nick@csse.uwa.edu.au>
- References: <20091110072125.L55567@epsilon.pair.com><C71F83C7.123CE%nick@csse.uwa.edu.au>
I would argue that a properly designed scripting language will provide ways to protect datanames found in dREL code, so there is no need to worry about inhibiting use of scripting languages. I personally always use the 'setattr' form of the python '.' attribute dereference when converting dREL code to Python, thereby avoiding any issues with embedded punctuation. Furthermore, as I argued in my other message today, dREL should also provide a way to quote datanames. On Tue, Nov 10, 2009 at 11:55 PM, Nick Spadaccini <nick@csse.uwa.edu.au> wrote: > 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 > -- 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]
- References:
- Re: [ddlm-group] CIF-2 changes (Herbert J. Bernstein)
- Re: [ddlm-group] CIF-2 changes (Nick Spadaccini)
- Prev by Date: Re: [ddlm-group] CIF-2 changes
- Next by Date: Re: [ddlm-group] CIF-2 changes
- Prev by thread: Re: [ddlm-group] CIF-2 changes
- Next by thread: Re: [ddlm-group] [THREAD 4] UTF8
- Index(es):