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

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

In my original spec I wrote it (at least in my mind) with embedded comments
as allowed in the compound data types, list and table since these were
comprised of other tokens (it was easier when these were comma separated,
but still workable in the space separated version). You can't have it in a
triple quote because # is a legitimate character within that structure.


On 1/10/10 4:01 AM, "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
wrote:

> The confusion arises from the original CIF 1.1 document which
> first discusses the allow whitespace characters, and then the
> syntax token <WhiteSpace>.  We should clarify it, but we
> should clarify the role of whitespace both for CIF1 and CIF2,
> not just in the CIF2 change document.
> 
> In any case, it appears that what we have so far _does_ permit
> comments within 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, Bollinger, John C wrote:
> 
>> 
>> On Thursday, September 30, 2010 2:37 PM, Herbert J. Bernstein wrote:
>> 
>>>   Working from the original DDLm/dREL spec, I did not see anything
>>> precluding comments within bracketed >costructs and have therefore
>>> programmed on the assumption that they have to be allowed.  The CIF2 spec
>>> simply >does not discuss the issue, but explcitly allows whitespace within
>>> bracketed constructs.
>>> 
>>>   We should decide what we really want here and document it
>> 
>> On Thursday, September 30, 2010 2:42 PM, Herbert J. Bernstein wrote;
>>> In paragraph 46, the CIF 1.1 spec says:
>>> 
>>> 46. White space comprises all appropriate combinations of spaces, tabs, ends
>>> of lines and comments, as well as the beginning of the file.
>> <WhiteSpace> are the characters able to delimit the lexical tokens.
>>> 
>>> So, as things now stand the proposed CIF2 spec _would_ allow comments within
>>> bracketed construct because it explcitly permits whitespace in bracketed
>>> constructs.
>> 
>> Unfortunately, the current draft of the Changes document contains a
>> definition of "whitespace" that does not include comments.  I'm not sure how
>> that came about or whether it has some purpose I do not see, but I find it a
>> bit strange.  I think it would at times be useful to have comments in
>> bracketed structures, and my existing code will allow it (in part because I
>> didn't recognize until now that there was a question about it).
>> 
>> Is there a reason why we should not reintroduce comments to the definition of
>> whitespace?
>> 
>> 
>> 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
>> 
> _______________________________________________
> 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

Reply to: [list | sender only]