Discussion List Archives

[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]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links