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

Dear James,

� I was under the impression that you were the chair of COMCIFS and
you have decreed that there is no mistake. �I, recalling the bitter
fights involved at the time, am very certain that the wording in
the spec is a mistake. �Time will tell as to who is right.

� The entire point of having a library of trip tests was to deal
with such boundary cases. �If the trip tests are no longer relevant,
I would suggest that COMCIFS have them taken down, put up a few
PDB and CCDC files and call it a day.

� As I said, I give up.

� Regards,
� � Herbert

At 1:48 PM +1100 10/29/10, James Hester wrote:
>Herbert, if you believe that there has been a mistake in Volume G,
>then I suggest that you raise your concerns with COMCIFS. �You may
>wish to produce examples of CIF files accessible to normal users to
>support your case that the published standard does not accord with
>normal practice. � I would suppose that all PDB and IUCr and CCDC
>archive files do conform to the published standard, but perhaps you
>have other information.
>
>On Fri, Oct 29, 2010 at 11:17 AM, Herbert J. Bernstein

><<mailto:[email protected]>[email protected]>

>wrote:
>
>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

> � � � � � � � � �<mailto:[email protected]>[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 <http://iucr.org>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:

>> <http://www.stjude.org/emaildisclaimer>www.stjude.org/emaildisclaimer
>> �_______________________________________________
>> �ddlm-group mailing list
>> �<mailto:[email protected]>[email protected]
>>
>><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>_______________________________________________
>ddlm-group mailing list
><mailto:[email protected]>[email protected]
><http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group

>
>
>
>
>--
>T +61 (02) 9717 9907
>F +61 (02) 9717 3145
>M +61 (04) 0249 4148
>

>_______________________________________________
>ddlm-group mailing list
>[email protected]
>http://scripts.iucr.org/mailman/listinfo/ddlm-group

--

=====================================================
�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]
=====================================================

_______________________________________________
ddlm-group mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/ddlm-group