[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Result of concatenation operator vote
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Result of concatenation operator vote
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Thu, 28 Oct 2010 22:46:48 -0400
- In-Reply-To: <AANLkTi=sfBSCGfUhFaAYEoe5+XUj+g03zxBsd7UtneSq@mail.gmail.com>
- References: <AANLkTim3DMuAuKxY5rVxZ46Jdt+M+Eaw+V5pFo24U5FU@mail.gmail.com><alpine.BSF.2.00.1010272003380.69742@epsilon.pair.com><AANLkTi=+pgWTQpN4_CkCgNigtO76x8g10wchpLYJpOmG@mail.gmail.com><alpine.BSF.2.00.1010272300170.23956@epsilon.pair.com><AANLkTinoFaLfwmSiA3t=7Jrm33-NcuEO5c3uAcEUzVMm@mail.gmail.com><alpine.BSF.2.00.1010280537590.39569@epsilon.pair.com><AANLkTi=sfBSCGfUhFaAYEoe5+XUj+g03zxBsd7UtneSq@mail.gmail.com>
Dear James, With some sort of a change in CIF2, the currently working line folding trip tests the work in CIF1 won't work in CIF2, so something has changed. Please look at the trip tests. ;\ has been legal and used for years. With that I give up. CIF will just have to split into even more conflicting dialects for a while. I'll support the full set of trip tests and you can treat some of them as a syntax error. What a waste. Regards, Herbert At 1:35 PM +1100 10/29/10, James Hester wrote: >Dear Herbert: > >It is clear from this discussion that the status of the line-folding >protocol is unchanged in CIF2. Both CIF1 and CIF2 are explicit >about tokens being separated by whitespace, and both CIF1 and CIF2 >do not allow backslashes to either post-elide or pre-elide the ><eol><semicolon> digraph. Likewise, those who wish to interpret the >line-folding protocol contrary to the published standard for CIF1 >and CIF2 will presumably continue to do so. > >I would therefore be prepared to state that the line-folding >protocol is unaffected by the CIF2 syntax changes when presenting >CIF2 to COMCIFS, if that is any help. > >If you wish to instead reopen the elide debate >(<http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00331.html>http://www.iucr.org/__data/iucr/lists/ddlm-group/msg00331.html), >with the commensurate time that will be required to reach a >conclusion, then I suggest that you put the question of reopening >the elide debate to a straw poll first, to find out if others are as >concerned as you about the issue. As you have argued forcefully on >several occasions, we need to wrap this up soon, and discussing >elides will not be quick. > >I am not in favour of reopening the elide discussion, as we are >likely to simply cover exactly the same ground as this time last >year, and take just as long about it as well. I strongly urge you >to delay or abandon discussion of this issue until after CIF2 has >been adopted by COMCIFS. > >James. > > >(some comments inserted below) > >On Thu, Oct 28, 2010 at 9:08 PM, Herbert J. Bernstein ><<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com> >wrote: > >Dear James, > > Nothing is impossible, but the fact remains that for CIF2, all the >uses of the backslash that had been agreed to for CIF1 were >explcitly rejected, largely at Nick's insistence that somehow we >were diverging from STAR. The oddity you have pointed out in the >"official" CIF1 syntax document is another case of Nick's insistence >which in fact diverges from CIF1 practice, existing code and >existing round-trip cases. We have somehow over the years entered >an absurd never-never land in which the official CIF documents say >one thing, and the established practice on which people do real work >is something very different. > > >As John B and I have pointed out, there is no use of backslash that >is allowed in CIF1 and not allowed in CIF2. What this group did >reject is a use of backslash to elide <eol> at a syntactic level. >Eliding <eol> within a datavalue *after* tokenisation, as the data >folding protocol does, is still perfectly legal in both CIF1 and >CIF2. > > > > If you don't believe me, see the trip test at > ><http://www.iucr.org/resources/cif/software/ciftest2/ciftest_2.1/outs/ciffold/longtext_out.cif>http://www.iucr.org/resources/cif/software/ciftest2/ciftest_2.1/outs/ciffold/longtext_out.cif > >which explicitly tests that the ;\ construct works for line folding. > > >This trip test contradicts the published CIF standards and is >therefore incorrect. Who do I submit the bug report to? > > > The line folding protocol is an essential reality, especially to >allow CIF to be used with Fortran. > > >I have no issue with the line folding protocol as published, in fact >it quite elegantly solves legacy issues. > > > The use of the required whitespace after everything except the last >token in a CIF document is an essential reality in lexical scans of >existing CIF documents. > > In the name of what is to me is an incomprensible adherence to a >constantly changing and undocumented STAR standard has resulted in >loss of functionality that is needed to keep current applications >and current CIF datasets in use. > > >There is no reason to bring the STAR standard into this, changeable >or otherwise. It is the detailed formal grammar and descriptive >text for CIF1 which does not envision use of backslash as you >propose. > > > Of course these issues can be resolved. I keep accumulating fudges >for CIFtbx and CBFlib to deal with them. The problem is that, >without any COMCIFS level agreement on what the preferred fudges >are, there is no reason to expect that the files my code reads and >writes will be compatible with the files that, say, your code reads >and writes, or compatible with the files that, say, John Westbrook's >code reads and writes, almost guaranteeing that CIF is going to >degenerate even more than it has into multiple idiosyncratic >dialects. To me this seems to be the antithesis of the goal of the >creation of COMCIFS -- which was, as its name says, to maintain the >CIF _standard_. > > >Indeed, we *are* trying to maintain a *standard*, and so it is most >unhelpful when members of the standards committee support and >actively advocate behaviour which directly contradicts the published >standard. > > > I apologize for sounding so preachy and stuffy, but I really think >it would be a good idea to resolve these issues in some commonly >agreed manner and try to keep CIF as a common language, rather than >heading further into multiple dialects. > > >On Thu, 28 Oct 2010, James Hester wrote: > >Dear Herbert, > >Thanks for your detailed response. I think I am failing to understand >something elementary. I see nothing in your comments below to indicate why >it would be impossible to use the line-folding protocol to split long lines >over multiple lines, for arbitrary CIF2 text. Additionally, I believe your >first example below would be a syntax error under both CIF1.1 and CIF2, >because the <eol><semicolon> sequence terminates the datavalue regardless of >following text. In other words, I know of nothing in CIF1.1 to indicate >that <eol><semicolon> terminates the datavalue only if there is whitespace >or <EOF> after the <eol><semicolon>. > >If I am incorrect in my thinking, I would appreciate a correction expressed >in terms of the formal CIF1.1 grammar. > >James. > >On Thu, Oct 28, 2010 at 2:27 PM, Herbert J. Bernstein ><<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com> wrote: > Dear James, > > The line folding protocol is in section 26 of > > > <http://www.iucr.org/resources/cif/spec/version1.1/semantics>http://www.iucr.org/resources/cif/spec/version1.1/semantics > > I tried to get agreement on continuing this use of the backslash > and that was firmly and explicitly rejected, effectively > removing the entire line folding protocol, which depends on it. > Even if we restore the use of the backslash, there has been a > significant change in the termination of a text field. In CIF > 1.1, text field can only end with <eol>; followed either by > whitespace or the end of a file, so the existing line folding > protocol allows > > ;\ > this is an example of an embedded text field > ;\ > > an embedded text field > ;\ > > ; > > which is no longer valid under CIF2 because all quoted fields > end on the first occurrence of their delimiter, and as stated in > the new syntax document, "CIF2 keywords, data block headers, > save frame headers, data names, and data values must all be > separated from each other by whitespace. Whitespace not > otherwise part of a CIF2 syntax element is significant only for > this purpose. > > Reasoning: The CIF1 specification relies implicitly on the > syntactic structure of the language to require whitespace > separators between syntax elements. The CIF2 syntax no longer > implicitly provides whitespace separators in some cases > (notably, after most types > of data values), therefore the requirement is now made > explicit." > > So under CIF2, the use of the elide to shield the <eol>; is > explcitly an error. > > It would be very nice to have the line folding back, either > in the form of the use of the backslash, or by using the > string concatenation operator. > > >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:yaya@dowling.edu>yaya@dowling.edu >===================================================== > >On Thu, 28 Oct 2010, James Hester wrote: > > I would be happy to indicate the status of the line > folding protocol under > the CIF2 draft when introducing the CIF2 draft to > COMCIFS. Perhaps you > could write a few words in reply to this email giving a > description of the > status of the line folding protocol under CIF2, as I'm not > sure why > line-folding and CIF2 are incompatible. > > On Thu, Oct 28, 2010 at 11:09 AM, Herbert J. Bernstein > > <<mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com> >wrote: > Dear James, > > I don't mind if the approval of CIF2 has priority if > the debate > on that ends before debate on the concatenation > operator, but > imasmuch as either the concatenation operator or some > other > replacement for the line folding protocol is > necessary before > CIF2 can become a full replacement for CIF1, I would > suggest > that the matter be brought to COMCIFS at the same > time > and we see what happens. > > I would also like to bring the issue of how we > transition > imgCIF before COMCIFS. That is anther area where > CIF2 does > not yet provide support. > > 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:yaya@dowling.edu>yaya@dowling.edu > ===================================================== > > > On Thu, 28 Oct 2010, James Hester wrote: > > My count is 2 in favour, 4 against, with Simon (whose > vote > doesn't appear to have come in) > potentially making that 3 in favour and 4 against. > These > are not entirely convincing numbers > for either side. However, although the proponents of > the > concatenation operator are free to > address COMCIFS on this question, a replay of this > vote > within COMCIFS would lead to at least 3 > opposed and at least one in favour, with Nick's > opposition > making it (at best) a 4-2 vote > against. So, I suggest that at this point we delay > any > further consideration of concatenation > until COMCIFS has approved CIF2. > > In a subsequent email I will therefore put the > current > CIF2 spec to a DDLm group vote, and > assuming it passes will present it to COMCIFS for > final > approval. > -- > T +61 (02) 9717 9907 > F +61 (02) 9717 3145 > M +61 (04) 0249 4148 > > > _______________________________________________ > ddlm-group mailing list > <mailto:ddlm-group@iucr.org>ddlm-group@iucr.org > > <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 ><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org ><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 ><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org ><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 >ddlm-group@iucr.org >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 yaya@dowling.edu ===================================================== _______________________________________________ ddlm-group mailing list ddlm-group@iucr.org http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- References:
- [ddlm-group] Result of concatenation operator vote (James Hester)
- Re: [ddlm-group] Result of concatenation operator vote (Herbert J. Bernstein)
- Re: [ddlm-group] Result of concatenation operator vote (James Hester)
- Re: [ddlm-group] Result of concatenation operator vote (Herbert J. Bernstein)
- Re: [ddlm-group] Result of concatenation operator vote (James Hester)
- Re: [ddlm-group] Result of concatenation operator vote (Herbert J. Bernstein)
- Re: [ddlm-group] Result of concatenation operator vote (James Hester)
- Prev by Date: Re: [ddlm-group] Result of concatenation operator vote. .. .
- Next by Date: Re: [ddlm-group] Result of concatenation operator vote. .. .
- Prev by thread: Re: [ddlm-group] Result of concatenation operator vote
- Next by thread: [ddlm-group] Vote on concatenation operator
- Index(es):