[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . .
- From: James Hester <jamesrhester@gmail.com>
- Date: Sat, 15 Jan 2011 15:28:15 +1100
- In-Reply-To: <alpine.BSF.2.00.1101142238230.68420@epsilon.pair.com>
- References: <AANLkTimdAavg2KCjPZTj1xDYXDQ1JLiQCkQb4snyBErZ@mail.gmail.com><alpine.BSF.2.00.1101120834010.42232@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EA8@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1101121400400.85750@epsilon.pair.com><alpine.BSF.2.00.1101121556380.31518@epsilon.pair.com><698308.91583.qm@web87015.mail.ird.yahoo.com><alpine.BSF.2.00.1101121845060.90622@epsilon.pair.com><alpine.BSF.2.00.1101131202050.27153@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EB8@SJMEMXMBS11.stjude.sjcrh.local><85782.48834.qm@web87007.mail.ird.yahoo.com><AANLkTik2X=SKJyCKKqYJ7_g=hHCcPAOKYbiiJujKCz5s@mail.gmail.com><alpine.BSF.2.00.1101140527560.94749@epsilon.pair.com><AANLkTi=41X-+kcBgk=2Xd7sbO2GXHTCJ1bTAowO-+JcD@mail.gmail.com><alpine.BSF.2.00.1101141014210.46682@epsilon.pair.com><8F77913624F7524AACD2A92EAF3BFA54166D7D1EBB@SJMEMXMBS11.stjude.sjcrh.local><alpine.BSF.2.00.1101141448160.88944@epsilon.pair.com><alpine.BSF.2.00.1101142238230.68420@epsilon.pair.com>
See my comments below. On Sat, Jan 15, 2011 at 2:50 PM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote: > Dear Simon, > > Please read both the DDLm and dREL documents, > and then reread John Bolliger's comments on > trying to force CIF2 not to be a programming > languages. I don't see how we are going to > properly support DDLm in a CIF2 context with > such an approach. We _need_ CIF2 to be a > programming language if it is to support dREL > to form DDLm dictionaries, because those dictionaries > are programs. This paragraph makes no sense whatsoever. Both my own proof-of-concept code and Nick and Syd's code show that dREL works fine with DDLm and CIF2 syntax. Herbert is therefore talking about a problem that doesn't exist. I advise everybody to examine the specification documents to assure themselves of this. If you, Herbert, disagree, give a concrete example of the problem, and not ex-cathedra assertions. > Sure, were can make some changes to DDLm snd > dREL, but we really should not try to drag > them into a programming-language-hostile environment. > On the contrary, we should be sure to provide > rich programming language support, which means > getting more pythonesque, not less. There is nothing hostile about CIF2 to programs. Quite the reverse, it is a reasonably elegant serialisation of a relational database, and as such provides the datastructure for dREL algorithms to operate on. If you think otherwise, please give a concrete example of how the current CIF2 syntax is "hostile" to dREL and DDLm, ideally with a particular dREL method calculating a particular value for a particular dataname. > dREL is already 90% compatible with Python. > I would suggest we consider go all the way and simply > make the dREL methods into Python scripts or scripts > in some other well-supported programming language, > make all string literals follow the string conventions > conventions of that language, adapt CIF2 to that > language. Maybe dREL is already that scripting > language, but in any case we are dealing with > programming language issues, and cannot avoid them. I do not see the problems you see. You will need to give concrete examples for me to grapple with. dREL is specifically designed for the abstract CIF datastructure (relational database). I would oppose any tinkering with it without a clear demonstration - using concrete datanames and algorithms (not vague assertions)- of exactly why it is not suited for purpose. > 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 Fri, 14 Jan 2011, Herbert J. Bernstein wrote: > >> Dear Colleagues, >> >> I would suggest recalling that this CIF2 exercise began with >> tryin to define a DDLm/dREL-friendly version of CIF. To the best >> of my knowledge, the current DDLm spec is at what is published >> on the IUCr web site under http://www.iucr.org/resources/cif/ddl/ddlm >> with draft documents from August 2008. I propose that we all >> take the time to review those documents and make a conscious >> effort to decide if we wish to make use of them as a >> base for CIF2 or not. They contain many points relevant >> to the current discussion. For example: >> >> 1. the top level page contains the bold-faced assurance to >> the community that "No changes are required in existing archival >> data files in order to apply domain dictionaries written in DDLm". >> Do we wish to return to that "minimally distruptive" approach, or >> do we wish to continue on the current "maximally disruptive >> approach" and why. >> >> 2. The DDLm document describes Lists and Arrays as being bracketed >> by [], Tuples as being bracketed by (), and Tables as being >> bracketed by {}. Do we wish to return to that spec, or to >> use the revised spec which avoids [], and why? >> >> 3. The dREL document describes rather pythonesque string literals >> with cooked, raw and Unicode strings, treble quotes, C-style elides and >> much more that has been rejected by this group. Do we wish to >> bring the full dREL data type collection into CIF2 or not, and >> why. If we reject some portion of the dREL data types, what >> shall we do when a dictionary method using those type generated >> a data item of a type we have rejected? >> >> I had been under the mistaken impression that much of what this >> group decided had been donwe to achieve compatability with >> the new STAR and with DDLm and dREL. It is now clear, that >> instead of achieving compatibility we have made integration >> of CIF2 with CIF1, STAR, DDLm and dREL more difficult. >> >> The more I look over the original DDLm and and dREL documents, >> the more convinced I am that we either need to revise CIF2 to >> conform with them, or we need to revise them to conform with >> CIF2 or both. >> >> It is time to start over. >> >> 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 Fri, 14 Jan 2011, Bollinger, John C wrote: >> >>> On Friday, January 14, 2011 9:23 AM, Herbert J. Bernstein wrote: >>>> hearing what others think on the current version of CIF2 feature by feature would help. >>> >>> I structure these comments after the changes document, and I comment primarily about the changes and additions in CIF2. If more is desired then I probably need a list of the CIF features about which comments are solicited. >>> >>> * Feature: Magic Code >>> This, or something like it, is necessary to enable CIF parsers to adapt automatically to CIF1 vs. CIF2 input. I consider that a worthwhile thing to be able to do, so I am in favor of this feature. >>> >>> * Feature: Unicode support This is my favorite new CIF feature, though I >>> think it could be slightly improved: 1) I think certain Unicode >>> character categories (space and control characters) should be forbidden >>> in data names 2) I think data block and save frame codes should follow >>> the same rules as data names (except for the leading underscore), >>> subject to line length limitations (it's not altogether clear from the >>> changes document whether they do, but I have supposed not) >>> >>> I do not object to limiting recognized whitespace characters and >>> newlines as CIF2 currently does. However, if (1) above were adopted >>> then it would provide a clearer path to possible future full adoption of >>> Unicode whitespace semantics. >>> >>> I remain satisfied with the compromise we reached on encoding. >>> >>> * Change: treatment of newline I am on record as favoring this sort of >>> treatment as far back as during the preparation of CIF 1.1, and I still >>> favor it. >>> >>> * Change: allowed whitespace-delimited data values I would be happier if >>> it were not necessary to place stronger restrictions on the ASCII >>> content of these values, but if list and table data types are retained >>> then I can live with it. For forward-looking compatibility, it might be >>> better to forbid Unicode whitespace from appearing in these, even though >>> allowing such characters is not a problem for CIF2. >>> >>> * Change: string delimiters ('") cannot be embedded in data values they >>> delimit As unusual as CIF1's rules for quoted data values are, I do not >>> favor changing them in CIF2. I would find the change more palatable >>> with the addition of some sort of escape or elide by which the delimiter >>> could be embedded, but more than that I would favor backwards >>> compatibility. >>> >>> * Restriction: text blocks cannot contain <newline>; This is not a >>> change from CIF 1.1 as far as I can tell, but our discussions have shown >>> that it differs at least from some older interpretations of CIF. I am >>> satisfied with it, and I prefer it for compatibility with CIF 1.1. If >>> there were evidence of a non-trivial body of CIFs relying on a different >>> interpretation, and if the changes to single-quoted string formatting >>> were reversed, then I might be persuaded to change my mind. >>> >>> * Feature: triple-quoted strings I have never been especially hot about >>> these, but I saw the advantage they provided when coupled with the >>> changes to single-quoted string syntax, and their use for quoting text >>> block delimiters. I also see a compatibility advantage to using >>> exclusively these for new syntax and semantics, such as we have recently >>> been discussing. I am mildly supportive. >>> >>> * Feature: list data type Inasmuch as this is supposedly needed for ddlm >>> / dREL, I'm OK with it. I imagine there are other reasonable use cases >>> as well, though none presently come to mind. I don't object to it, but >>> neither do I particularly favor it. >>> >>> * Feature: table data type My opinion of this is pretty much the same as >>> of the list data type. I am slightly more negative about it because it >>> requires a restriction of allowable whitespace-delimited data values >>> relative to CIF 1.1, but I still do not object. >>> >>> * Undocumented Change: updated data model I have lately realized that >>> many of the CIF2 syntax changes imply changes to the CIF data model, but >>> that I find no documentation of those data model changes. Really, the >>> data model updates should have been settled first, for the syntax serves >>> the model, not the other way around. This would answer questions such >>> as the one I recently injected into the elide discussion, about whether >>> elides should be accepted that represent characters outside the revised >>> CIF character set. >>> >>> I have no problem with extension of the CIF1 data model, but I think we >>> need to better characterize the details of the new model. >>> >>> >>> Regards, >>> >>> 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 >>> ddlm-group@iucr.org >>> http://scripts.iucr.org/mailman/listinfo/ddlm-group >>> >> _______________________________________________ >> ddlm-group mailing list >> ddlm-group@iucr.org >> http://scripts.iucr.org/mailman/listinfo/ddlm-group >> > _______________________________________________ > ddlm-group mailing list > ddlm-group@iucr.org > 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
Reply to: [list | sender only]
- References:
- [ddlm-group] Simon's elide proposal (James Hester)
- Re: [ddlm-group] Simon's elide proposal (Herbert J. Bernstein)
- Re: [ddlm-group] Simon's elide proposal (Bollinger, John C)
- Re: [ddlm-group] Simon's elide proposal (Herbert J. Bernstein)
- Re: [ddlm-group] Simon's elide proposal (Herbert J. Bernstein)
- Re: [ddlm-group] Simon's elide proposal (SIMON WESTRIP)
- Re: [ddlm-group] Simon's elide proposal (Herbert J. Bernstein)
- [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (Bollinger, John C)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (SIMON WESTRIP)
- Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. . (James Hester)
- Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. . (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. . (James Hester)
- Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. . (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . . (Bollinger, John C)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . . (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . . (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . .
- Next by Date: Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . .. .
- Prev by thread: Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . .
- Next by thread: Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . . .
- Index(es):