Re: [ddlm-group] Result of concatenation operator vote. .. .

Dear John,

� A mistake is still a mistake, no matter how many times it gets repeated.
The requirement to scan one character ahead to terminate a token by
finding whitespace at the lexical level goes back to the first
implementations of CIF. �That was what was being removed in CIF2.
That removal has consequences.

� Efforts to get clear and unambiguous statments of both STAR
and CIF syntax that are actually consistent with the format of
existing files would be a good idea. but it seems that we never
manage to do that because documenting that reality seems to
always cause somebody concern. �The result is that we have a large
and growing of CIF files that conform to a variety of different
undocumented specs.

� It is a shame.

� Regards,
� � 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
� � � � � � � � �[email protected]
=====================================================

On Thu, 28 Oct 2010, Bollinger, John C wrote:

>
> On Thursday, October 28, 2010 4:48 PM, Herbert J. Bernstein wrote:
>>
>> Let me make this absolutely clear:
>>
>> ;\
>>
>> does not violate the CIF1.1 syntax. �It violates an incorrect
>> description of the CIF1.1 syntax. �This is about as silly as saying
>> the "would that it were the case" violates English syntax because
>> Microsoft word has a grammer checker that does not know about the
>> subjunctive.
>
> I suppose, then, that I am at a loss as to where to find a correct description of the CIF 1.1 syntax. �The spec currently available online at iucr.org agrees with IT vol. G.:
>
> 1) as ITG puts it, "A text field delimited by the <eol>; digraph may not include a semicolon at the start of a line of text as part of its value." �(International Tables vol. G (2005), Section 2.2.7.1.4, numbered paragraph (18).)
>
> 2) The formal grammars presented in both places do not permit a semicolon to appear at the beginning of a line of text inside a text field. �According to them, the first <eol>; digraph following the opening delimiter can only parse as the closing delimiter.
>
> 3) The explanations of both versions of the formal grammar repeat the same restriction on lines inside text fields: "[...] the first character cannot be a semicolon." (ITG 2.2.7.3, numbered paragraph (49))
>
> The specifications available to me are explicit, consistent, repetitive, and clear on this point. �Furthermore, both versions of the specification say
>
> 4) Tokens are separated by whitespace (ITG 2.2.3, third paragraph), and
>
> 5) "For a semicolon-delimited text string, failure to provide trailing white space is an error." �(ITG 2.2.7.3, numbered paragraph (56))
>
>
> Do you have a more authoritative reference than ITG? �Or official errata that alter these provisions? �Or an authoritative supplemental specification that changes them? Where can I find a correct specification?
>
>
> Thanks,
>
> 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
> [email protected]
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group