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

Re: [ddlm-group] Revisiting list delimiters. .. .

The only issue to which I think I should respond is whether [,,]
conforms to James proposed productions

1. <list> = '[' <whitespace>* {<listdatavalue> {<comma or
whitespace><listdatavalue>}*}* ']'

2. <listdatavalue> = {<list>|<string>}<whitespace>*

The question would seem to be whether an empty string is a string.
While I think such a strong is best presented as '' or "" or . or ?
in the whitespace delimited context, I see no issue with a blank
delimited empty string in the comma delimited context.  However,
whether that interpretation survives the discussion or not,
I still favor James' proposed productions.


At 12:31 PM -0500 4/7/11, Bollinger, John C wrote:
>On Thursday, April 07, 2011 9:40 AM, Herbert J. Bernstein 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.
>The productions for using whitespace-only list item separators must 
>be essentially the same as those for whitespace-only loop item 
>separators.  I infer, therefore, that CBFlib must also already have 
>productions that can be easily adapted to the current draft spec, or 
>else that it already chooses a different path anyway.  Syntactic 
>consistency is one of the advantages -- for both people and programs 
>-- of using the same separators everywhere.
>>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.
>Inasmuch as we can postulate programs that perform such 
>transformations on CIF2 files, and that we can suppose that one of 
>the things they might do is normalize list separators, James' 
>proposal is not inconsistent with the tradition you describe.  I 
>don't see that as any kind of justification for the proposal, 
>>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
>I agree that it is not worthwhile to repeat the earlier discussion, 
>but that is no reason to jump directly to a vote.  It seems 
>reasonable to instead focus on any new information or insights that 
>did not inform the previous discussion, and then to consider whether 
>their combination with the considerations already discussed leads 
>anyone to change their previous opinion.
>So, what is the new information we should consider?  James raised 
>these points:
>JH> the only fully-functional software for processing DDLm domain 
>dictionaries (Nick, Syd and Ian's demonstration software) expects a 
>comma separator
>JH> [James's] understanding is that Syd and Nick (now) are strongly 
>in favour of sticking with comma as the list separator for STAR2
>JH> other non-CIF domains are already using comma as a list 
>separator in STAR2 data files.
>JH> for some, a comma may be a useful visual aid for distinguishing 
>looped items and listed items.
>I responded to each of those points in my first message yesterday: 
>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg01244.html.  The 
>short form is: (a) the direction of STAR2 is not persuasive (and I 
>now add that James's proposal still diverges from STAR2), (b) the 
>demo software will have to be changed anyway, including in this 
>area, and (c) syntactically distinguishing looped and listed items 
>has significant drawbacks directly associated with it.
>>As you can tell, I am in favor of James' productions.
>Are you?  I know you favor allowing both whitespace and comma 
>separators, but I think you misread James' productions when you 
>assert (elsewhere) that [,,] would match them.  I don't read them 
>that way, and James previously wrote that it was not his intention 
>to allow that sort of construct.
>Furthermore, the productions as currently written are flawed at 
>least because they do not permit tables as list items.  They also 
>yield odd results for where whitespace is allowed relative to commas 
>(allowed before, but not after).  Those issues can be addressed with 
>relative ease, of course, but they're a good reason to defer voting 
>on specific productions.
>Email Disclaimer:  www.stjude.org/emaildisclaimer
>ddlm-group mailing list

  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

ddlm-group mailing list

Reply to: [list | sender only]