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

Re: [ddlm-group] A modest addition to the DDLm spec. .

We have already forbidding a variety of characters in non-quoted strings.
We also have changes the original star approach when we went to bracketed
constructs.  This is a change fairly easily implemented at the lexical
level.

Both the treble quote and the \n; quote make the result very much more 
difficult to read.  This change  would make CIF consistent with python 
practice and allow much neater CIFS without getting into the elide issue.

I don't see why allowing comments in the middle here is any worse than
the comments that are allowed in the middle of bracketed constructs.

=====================================================
  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, 30 Sep 2010, Nick Spadaccini wrote:

> This in fact is not a DDLm issue. It is a STAR and CIF syntax issue. The
> broken regex example represents 3 separate data values to a single data name
> with no loop construct to protect it - hence it violates the very basis of
> the syntactic structure of both CIF and STAR. Apart from that it is fine!
>
> You cannot parse these strings unambiguously unless you have a context that
> says a data value that follows a _item_type_list.construct is completely
> different to every other syntactic construct. I do not think that would not
> be a wise variation to CIF2.
>
> The triple quote solution suggested by John is the most sensible approach,
> if the semi-colon delimited text is unfavoured.
>
> Nick.
>
>
> On 30/09/10 11:39 PM, "Bollinger, John C" <John.Bollinger@STJUDE.ORG> wrote:
>
>> On Thursday, September 30, 2010 10:18 AM, SIMON WESTRIP wrote:
>>
>>> First thought is how does this work in loops?
>>>
>>> loop_ _item
>>> 'abc' + 'def'
>>
>> One specific (but synthetic) example I was thinking of was along the same
>> lines:
>>
>> loop_
>>  _amino_acid.code
>>  _amino_acid.optical_rotation_direction
>>  'ALA' +
>>  'ARG' +
>>  'LEU' -
>>
>>> But I need to check whether + is one of the characters that is not allowed to
>>> start a
>>> non-delimited string...
>>
>> It is not.  Those are " ' _ $ [ {
>> If the proposal is adopted then adding + to that list would reduce the added
>> complications for parsing.  That would be incompatible with using the optional
>> leading + with numeric values, however.
>>
>>> Otherwise I see no reason not to explore this.
>>
>> I see no reason at all not to explore it.  Notwithstanding the above, I have
>> not yet formed an opinion on this question.
>>
>>
>> Regards,
>>
>> John
>> --
>> John C. Bollinger, Ph.D.
>> Department of Structural Biology
>> St. Jude Children's Research Hospital
>>
>>
>> Email Disclaimer:  www.stjude.org/emaildisclaimer
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
> 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]