Discussion List Archives

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

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


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

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