Discussion List Archives

[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.

   Regards,
     Herbert

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, 
>however.
>
>
>>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.
>
>
>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.
>
>
>Regards,
>
>John
>
>
>Email Disclaimer:  www.stjude.org/emaildisclaimer
>
>_______________________________________________
>ddlm-group mailing list
>ddlm-group@iucr.org
>http://scripts.iucr.org/mailman/listinfo/ddlm-group


-- 
=====================================================
  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
=====================================================
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links