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

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

Dear Colleagues,

   Several times in the course of discussion CIF2, proposals have
been opposed on grounds of conflict with STAR syntax.  It would
be a great help in understanding these objections if there were
a document to which we could refer clearly specifying the STAR
syntax.  The best I have found thus far is:

http://www.iucr.org/__data/iucr/cif/standard/cifstd4.html
(which is taken from Acta Cryst. (1991). A47, 655-685)

Is that the complete document to which we should refer?

   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
                  yaya@dowling.edu
=====================================================

On Thu, 28 Oct 2010, SIMON WESTRIP wrote:

>> --===============2119001675==
> Content-Type: multipart/alternative; boundary="0-659398189-1288274737=:4610"
>
>> --0-659398189-1288274737=:4610
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: quoted-printable
>
> Just for the record - my vote is 'yes'.=0A=0AIn line with Herbert's view, i=
> t might also be worth considering that it is=0Aimpossible to specify a mult=
> iline data value that includes all of the CIF =0Adelimiters.=0AGranted this=
> is an unlikely scenario, but to me this is a deficiency of the base =0Asyn=
> tax.=0ACIF2 provides an opportunity to deal with such issues at the syntax =
> level, =0Arather than=0Avia semantics that are not part of the standard.=0A=
> =0ACheers=0A=0ASimon=0A=0A=0A=0A=0A________________________________=0AFrom:=
> Herbert J. Bernstein <yaya@bernstein-plus-sons.com>=0ATo: Group finalising=
> DDLm and associated dictionaries <ddlm-group@iucr.org>=0ASent: Thursday, 2=
> 8 October, 2010 11:08:36=0ASubject: Re: [ddlm-group] Result of concatenatio=
> n operator vote=0A=0ADear James,=0A=0A  Nothing is impossible, but the fact=
> remains that for CIF2, all the uses of the =0Abackslash that had been agre=
> ed to for CIF1 were explcitly rejected, largely at =0ANick's insistence tha=
> t somehow we were diverging from STAR. The oddity you have =0Apointed out i=
> n the "official" CIF1 syntax document is another case of Nick's =0Ainsisten=
> ce which in fact diverges from CIF1 practice, existing code and existing =
> =0Around-trip cases.  We have somehow over the years entered an absurd neve=
> r-never =0Aland in which the official CIF documents say one thing, and the =
> established =0Apractice on which people do real work is something very diff=
> erent.=0A=0A  If you don't believe me, see the trip test at=0A=0Ahttp://www=
> .iucr.org/resources/cif/software/ciftest2/ciftest_2.1/outs/ciffold/longtext=
> _out.cif=0A=0A=0Awhich explicitly tests that the ;\ construct works for lin=
> e folding.=0A=0A  The line folding protocol is an essential reality, especi=
> ally to allow CIF to =0Abe used with Fortran.=0A=0A  The use of the require=
> d whitespace after everything except the last token in a =0ACIF document is=
> an essential reality in lexical scans of existing CIF documents.=0A=0A  In=
> the name of what is to me is an incomprensible adherence to a constantly =
> =0Achanging and undocumented STAR standard has resulted in loss of function=
> ality =0Athat is needed to keep current applications and current CIF datase=
> ts in use.=0A=0A  Of course these issues can be resolved.  I keep accumulat=
> ing fudges for CIFtbx =0Aand CBFlib to deal with them.  The problem is that=
> , without any COMCIFS level =0Aagreement on what the preferred fudges are, =
> there is no reason to expect that =0Athe files my code reads and writes wil=
> l be compatible with the files that, say, =0Ayour code reads and writes, or=
> compatible with the files that, say, John =0AWestbrook's code reads and wr=
> ites, almost guaranteeing that CIF is going to =0Adegenerate even more than=
> it has into multiple idiosyncratic dialects.  To me =0Athis seems to be th=
> e antithesis of the goal of the creation of COMCIFS -- which =0Awas, as its=
> name says, to maintain the CIF _standard_.=0A=0A  I apologize for sounding=
> so preachy and stuffy, but I really think it would be =0Aa good idea to re=
> solve these issues in some commonly agreed manner and try to =0Akeep CIF as=
> a common language, rather than heading further into multiple =0Adialects.=
> =0A=0A  Regards,=0A    Herbert=0A=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0AHerbert J. Bernstein, Profe=
> ssor of Computer Science=0A   Dowling College, Kramer Science Center, KSC 1=
> 21=0A        Idle Hour Blvd, Oakdale, NY, 11769=0A=0A                 +1-63=
> 1-244-3035=0A                yaya@dowling.edu=0A=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=0AOn Thu, 28 O=
> ct 2010, James Hester wrote:=0A=0A> Dear Herbert,=0A> =0A> Thanks for your =
> detailed response. I think I am failing to understand=0A> something element=
> ary.  I see nothing in your comments below to indicate why=0A> it would be =
> impossible to use the line-folding protocol to split long lines=0A> over mu=
> ltiple lines, for arbitrary CIF2 text.  Additionally, I believe your=0A> fi=
> rst example below would be a syntax error under both CIF1.1 and CIF2,=0A> b=
> ecause the <eol><semicolon> sequence terminates the datavalue regardless of=
> =0A> following text.  In other words, I know of nothing in CIF1.1 to indica=
> te=0A> that <eol><semicolon> terminates the datavalue only if there is whit=
> espace=0A> or <EOF> after the <eol><semicolon>.=0A> =0A> If I am incorrect =
> in my thinking, I would appreciate a correction expressed=0A> in terms of t=
> he formal CIF1.1 grammar.=0A> =0A> James.=0A> =0A> On Thu, Oct 28, 2010 at =
> 2:27 PM, Herbert J. Bernstein=0A> <yaya@bernstein-plus-sons.com> wrote:=0A>=
>       Dear James,=0A> =0A>        The line folding protocol is in section =
> 26 of=0A> =0A>      http://www.iucr.org/resources/cif/spec/version1.1/seman=
> tics=0A> =0A>       I tried to get agreement on continuing this use of the =
> backslash=0A>       and that was firmly and explicitly rejected, effectivel=
> y=0A>       removing the entire line folding protocol, which depends on it.=
> =0A>        Even if we restore the use of the backslash, there has been a=
> =0A>       significant change in the termination of a text field.  In CIF=
> =0A>       1.1, text field can only end with <eol>; followed either by=0A> =
>      whitespace or the end of a file, so the existing line folding=0A>    =
>   protocol allows=0A> =0A>       ;\=0A>       this is an example of an emb=
> edded text field=0A>       ;\=0A> =0A>       an embedded text field=0A>    =
>   ;\=0A> =0A>       ;=0A> =0A>       which is no longer valid under CIF2 b=
> ecause all quoted fields=0A>       end on the first occurrence of their del=
> imiter, and as stated in=0A>       the new syntax document, "CIF2 keywords,=
> data block headers,=0A>       save frame headers, data names, and data val=
> ues must all be=0A>       separated from each other by whitespace. Whitespa=
> ce not=0A>       otherwise part of a CIF2 syntax element is significant onl=
> y for=0A>       this purpose.=0A> =0A>       Reasoning: The CIF1 specificat=
> ion relies implicitly on the=0A>       syntactic structure of the language =
> to require whitespace=0A>       separators between syntax elements. The CIF=
> 2 syntax no longer=0A>       implicitly provides whitespace separators in s=
> ome cases=0A>       (notably, after most types=0A>       of data values), t=
> herefore the requirement is now made=0A>       explicit."=0A> =0A>       So=
> under CIF2, the use of the elide to shield the <eol>; is=0A>       explcit=
> ly an error.=0A> =0A>       It would be very nice to have the line folding =
> back, either=0A>       in the form of the use of the backslash, or by using=
> the=0A>       string concatenation operator.=0A> =0A> =0A> Regards,=0A>  H=
> erbert=0A> =0A> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A>  Herbert J. Bernstein, Professor of Compute=
>
>
> [*** Terminated Message ***]
>
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]