[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Revisiting list delimiters. .
- To: Group finalising DDLm and associated dictionaries <[email protected]>
- Subject: Re: [ddlm-group] Revisiting list delimiters. .
- From: James Hester <[email protected]>
- Date: Thu, 28 Apr 2011 16:26:52 +1000
- In-Reply-To: <[email protected]>
- References: <[email protected]><[email protected]><[email protected]><[email protected]><[email protected]>
Dear DDLm members, It is clear that reintroducing commas as list delimiters is not without issues. I would therefore like to drop this proposal (for now) in the interest of making progress. I will therefore shortly be presenting a version of the DDLm specification recast in terms of the currently agreed CIF2 syntax. Separately I will introduce a thread to remove comma from the list of acceptable characters in a non-delimited string. On Fri, Apr 8, 2011 at 12:40 AM, Herbert J. Bernstein <[email protected]> wrote: > Having already done the code for essentially those > productions in the current release of CBFlib, for me, > it is less work to adapt to James' productions for CIF2 > than to disable the use of commas, so for me accepting > Nick's lists as valid is easier that making them into > a syntax error. > > CIF has a long tradition of liberal parsers for reads of > CIFs, accepting a wide variety of alternate presentations > of the same information, and writers that produce nice > neat, human readable versions. �I think James' proposal > is completely consistent with that tradition. > > Rather than a long repeat of the earlier discussion. �I > would suggest simply voting on James' productions independent > of the more difficult issue of any additional semantic > restrictions (e.g. what should be rejected on read as an error > even though it conforms to the productions, or what > should be accepted on read, but not written by a conformant > writer). �If the productions are acceptable, then it is > worth having the more detailed discussion. �If the productions > are not acceptable, there is no point in discussing the > rest. > > As you can tell, I am in favor of James' productions. > > ===================================================== > �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 protected] > ===================================================== > > On Thu, 7 Apr 2011, Bollinger, John C wrote: > >> >> On Thursday, April 07, 2011 2:34 AM, James Hester wrote: >> >>> I apologise for the lack of detail in my introductory posting. If >>> there is to be no quick agreement on the following, more formal, >>> proposal, then I am happy to withdraw the proposal completely and we >>> will continue on our previously agreed path. >>> >>> Note that I see no value in picking over Nick et. al's code as that >>> code is not the final arbiter of every detail of what is or isn't in >>> the standard - I was simply pointing out that it would be less work to >>> fix the code to conform to the new standard if we don't deviate too >>> far from the original. >>> >>> Here is my formal proposal: that a list be described by the following >>> productions: >>> >>> <list> = '[' <whitespace>* {<listdatavalue> {<comma or >>> whitespace><listdatavalue>}*}* ']' >>> <listdatavalue> = {<list>|<string>}<whitespace>* >> >> I still maintain that the situation is essentially unchanged from the >> last time this matter was discussed. �In particular, unless I greatly >> underestimate the relative difficulties of the software modifications >> that would be needed, the significance of any one-time cost difference >> for those changes is miniscule relative to that of the ongoing (but less >> tangible) costs of adopting an otherwise inferior solution. >> >> I acknowledge that commas, whitespace, and combinations of those as >> token separators all have merits, but from the perspective of CIF >> overall, I firmly believe that whitespace as the only list token >> separators remains the best solution. �I withhold further technical >> commentary at this time, in the hope that it will be unnecessary. >> >> >> Regards, >> >> John >> >> >> Email Disclaimer: �www.stjude.org/emaildisclaimer >> >> _______________________________________________ >> ddlm-group mailing list >> [email protected] >> http://scripts.iucr.org/mailman/listinfo/ddlm-group >> > _______________________________________________ > ddlm-group mailing list > [email protected] > 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 protected] http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] Revisiting list delimiters (James Hester)
- Re: [ddlm-group] Revisiting list delimiters (Herbert J. Bernstein)
- Re: [ddlm-group] Revisiting list delimiters (James Hester)
- Re: [ddlm-group] Revisiting list delimiters. . (Bollinger, John C)
- Re: [ddlm-group] Revisiting list delimiters. . (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Revisiting list delimiters
- Next by Date: [ddlm-group] Removing comma from non-delimited strings
- Prev by thread: Re: [ddlm-group] Revisiting list delimiters. .. .. .
- Next by thread: Re: [ddlm-group] Revisiting list delimiters. .
- Index(es):