Discussion List Archives

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

Re: [ddlm-group] Space as a list item separator>

I thought you had your vote and had decided not to support commas in
lists, but if it is still being discussed ...

Actually, while I agree that it is probably an error to have ,, for ,.,
it is likely to be a recoverable error, so I have included the option
of such recovery in CIFtbx4 and will be adding it in CBFlib, but in
both cases as conditional on whether commas are allowed.

   -- Herbert

=====================================================
  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 Thu, 3 Dec 2009, Nick Spadaccini wrote:

> If commas are to be separators in lists or tables then yes they must appear
> within delimited strings only, and are restricted from the character set for
> non-delimited strings -  I didn't include commas in last email on
> non-delimited restrictions.
>
> Depending on the votes we may not need to consider commas as special.
>
> As for adjacent commas there seems to be a view that one should "create
> data" in these situations. Both . and ? have very specific and different
> meanings (though there are erroneously used interchangeably) but above all
> they are user specified values. That is the user is telling you that the
> value is either ? or . Adjacent commas is a error, and in my opinion one
> from which you cannot recover. To infer from [1,2,,3] that the value is ? or
> . is no different to inferring 0, -99 or "blah". Even if it were inferred to
> be ?, what does that mean to a list that is bound to be operationally within
> some dREL code. What does the evaluator do with ? ?
>
> Nick
>
> On 3/12/09 3:00 AM, "Joe Krahn" <krahn@niehs.nih.gov> wrote:
>
>> I assume that quoting rules are the same: any string containing
>> delimiter characters must be quoted. Normally, that is just whit space,
>> but includes comma in the list context.
>>
>> Also, are adjacent commas invalid, or valid as the undefined ".", or as
>> the unknown "?"?
>>
>> Joe
>>
>> Nick Spadaccini wrote:
>>> Since this issue is not yet fully closed, for clarification as delimiters of
>>> tokens within a compound data type, comma and space are not exactly
>>> equivalent. The delimiters (that are equivalent) are
>>>
>>>  [:space:]+  # --- for white space delimited
>>>
>>>  [:space:]* , [:space:]*  # --- for comma delimited
>>>
>>> [:space:] matches a single whitespace character, * is the Kleene Star
>>> meaning zero (0) or more instances of a matche and + is the Kleene Plus
>>> meaning one (1) or more instances of the match.
>>>
>>> With that qualification, I agree with Herb's assessment.
>>>
>>> On 1/12/09 8:35 PM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
>>> wrote:
>>>
>>>> If both comma and space are permitted then I would treat
>>>>
>>>> [1, 2, 3  4 ]   or  [1,2,3 4]
>>>>
>>>> as equivalent and equivalent to
>>>>
>>>> [1 2 3 4] and [1 , 2 , 3 , 4] and [ 1 2 3 4 ]
>>>>
>>>> At least that is the way I have coded CIFtbx and CBFlib.
>>>> =====================================================
>>>>   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, 1 Dec 2009, John Westbrook wrote:
>>>>
>>>>> Could I ask for a clarification of the interpretation of a mixed case
>>>>> such as:
>>>>>
>>>>> [1, 2, 3  4 ]   or  [1,2,3 4]
>>>>>
>>>>> If quote and space are permitted are the above going to satisfy the
>>>>> syntax requiremens?
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> Herbert J. Bernstein wrote:
>>>>>> First amending the arguments
>>>>>>
>>>>>> To summarise the arguments:
>>>>>>
>>>>>> 1. In favour of both space and comma
>>>>>>    - comma is used in some other non-CIF contexts as a list delimiter
>>>>>>    - comma allows a large subset of lists and arrays to be carried
>>>>>> opaquely in CIF 1 and CIF 1.1 documents.
>>>>>>
>>>>>> 2. Against comma:
>>>>>>    - A single type of separator makes the grammar simpler
>>>>>>    - Space is used everywhere else in CIF as a separator (consistency)
>>>>>>    - Comma can then be used in non-delimited strings
>>>>>>
>>>>>> Then
>>>>>>
>>>>>> I vote for comma and space -- Herbert
>>>>>>
>>>>>> =====================================================
>>>>>>  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, 1 Dec 2009, James Hester wrote:
>>>>>>
>>>>>>> Dear CIF2 people: the time has come to vote on the list item separator
>>>>>>> issue.  Firstly: as far as I know, nobody is against space as a
>>>>>>> separator,
>>>>>>> so spaces will be possible list item separators.  Some may be against
>>>>>>> commas, so this vote is on whether or not to allow commas.
>>>>>>>
>>>>>>> To summarise the arguments:
>>>>>>>
>>>>>>> 1. In favour of both space and comma
>>>>>>>    - comma is used in some other non-CIF contexts as a list delimiter
>>>>>>>
>>>>>>> 2. Against comma:
>>>>>>>    - A single type of separator makes the grammar simpler
>>>>>>>    - Space is used everywhere else in CIF as a separator (consistency)
>>>>>>>    - Comma can then be used in non-delimited strings
>>>>>>>
>>>>>>> Space only: Nick, James (Nick is here)
>>>>>>> Comma and Space: ?
>>>>>>>
>>>>>>> On Tue, Dec 1, 2009 at 5:30 PM, James Hester <jamesrhester@gmail.com>
>>>>>>> wrote:
>>>>>>>       More specifically, CIF1.1 excludes square brackets as the first
>>>>>>>       character in a non-delimited string.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Dec 1, 2009 at 9:33 AM, James Hester <jamesrhester@gmail.com>
>>>>>>> wrote:
>>>>>>>       Dear Herbert: as CIF 1.1 doesn't define lists, I'm not
>>>>>>>       sure why you suggest that the example below is a valid
>>>>>>>       tag.
>>>>>>>
>>>>>>>       On Tue, Dec 1, 2009 at 12:36 AM, Herbert J. Bernstein
>>>>>>>       <yaya@bernstein-plus-sons.com> wrote:
>>>>>>>             Sorry something got lost in the prior message.
>>>>>>>              It should have
>>>>>>>             read:
>>>>>>>
>>>>>>>                   Dear Colleagues,
>>>>>>>
>>>>>>>                    Back to the question of commas.
>>>>>>>                    If you accept the desirability of
>>>>>>>                   having a CIF 1.5, commas in lists
>>>>>>>                   become very useful.  Someone with
>>>>>>>                   a CIF 1.1 editor will be able to
>>>>>>>                   prepare a CIF 1.5 file for many
>>>>>>>                   useful cases by doing all lists
>>>>>>>                   with commas and no embedded blanks
>>>>>>>                   as long as they can make their
>>>>>>>                   lists fit on single lines.  In CIF
>>>>>>>                   1.1
>>>>>>>
>>>>>>>                   [[1,2,3],[4,5,6],[7,8,9]]
>>>>>>>
>>>>>>>                   is a valid value for a tag, but
>>>>>>>
>>>>>>>                   [[1 2 3] [4 5 6] [7 8 9]]
>>>>>>>
>>>>>>> is not.
>>>>>>>
>>>>>>>
>>>>>>> No, neither example is a valid CIF 1.1 tag.  CIF 1.1 explicitly
>>>>>>> excludes brackets as the first character of a non-delimited
>>>>>>> string.
>>>>>>>
>>>>>>>
>>>>>>>             Having the option of commas in lists
>>>>>>>             will help to smooth the
>>>>>>>             transition for at least some people.
>>>>>>>
>>>>>>>
>>>>>>>
>
> 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
>
_______________________________________________
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