[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 <[email protected]>
- Subject: Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
- From: "Herbert J. Bernstein" <[email protected]>
- Date: Tue, 18 Jan 2011 05:55:08 -0500 (EST)
- In-Reply-To: <[email protected]>
- References: <[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]><[email protected]>
Once we settle our goals, I will be happy to explore how well value generation does or does not work until the resulting scheme for CIF1 documents. Right now I see a conflict when you cannot write the alias so that the dictionary tag is the CIF1 tag rather than the CIF2 tag, but if there turns out to be a way to conform both to CIF2 and to work fully with value generation in a CIF1 context, that would achieve the goal of my suggestion. First it would help to know if full CIF1 interoperability is or is not one of our goals. ===================================================== 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] ===================================================== On Tue, 18 Jan 2011, James Hester wrote: > David's approach is perfectly workable for the tasks Herbert > describes, and is the proper way to operate in the CIF framework. We > are agreed that the alias mechanism operates adequately for validating > existing values in a CIF1 file using a DDLm dictionary. Herbert's > concern is that the DDLm framework cannot produce values for missing > CIF1 tags. This is not true. Given a missing CIF1 tag, the > validation software looks for a dataname for which that tag is given > as an alias in the DDLm dictionary, and then calculates the value of > the DDLm dataname thus found. There is absolutely no need for any new > command on the dREL level. All that is required is for DDLm > dictionaries to include equivalent tags, which is not a software > issue. > > The CIF2-DDLm-dREL system works as advertised. No changes are indeed > required to archival datafiles in order to apply DDLm dictionaries. It > is in fact transparently simple to apply DDLm dictionaries to CIF1 > data files. There is certainly no justification for revisiting CIF2, > or fiddling around with dREL. > > Work commitments prevent me from answering in a more timely fashion > the various incorrect statements and interpretations that have been > flying around over the weekend. I will be attempting to do this over > the next few days, and also to guide these discussions to some > conclusion. > > On Tue, Jan 18, 2011 at 11:14 AM, Herbert J. Bernstein > <[email protected]> wrote: >> Dear David, >> >> �The promise on te IUCr website is very clear and in bold face >> >> "No changes are required in existing archival data files in order to apply >> domain dictionaries written in DDLm" >> >> The change I have proposed or something of similar power is required in >> order to be able apply DDLm dictionaries fully to CIF1 files so that both >> validation and filling in or missing values can be done in terms of the >> actual tags in the files, not just in terms of tags acceptable under CIF2. >> >> I was willing to accept the sacrifice of such full functionality as promised >> when we did not have a full technical solution on the table. Now we have >> one. If somebody has a better technical solution, that is wonderful, but I >> cannot and will not support retreating from that promise again, not that we >> seem to have a way to keep it. >> >> I do not understand what you mean by DDLm not being forwardly compatible, >> but I do under stand what applying a DDLm dictionary to a file means, and if >> that file is a CIF1 data file, then we need a way to have the DDLm >> dictionary, which is itself a CIF2 file, work with the CIF1 tags directly in >> its methods. �If all the methods can do is work in terms of DDL2 data names >> then they cannot populate missing CIF1 values and their method-generated >> validation error messages (as opposed to control program generated >> validation error messages) cannot be done in terms of CIF1 tags, making them >> much less useful. >> >> I don't see how to use aliases to do this, unless we extend the alias >> definition to essentially do the same thing as the change I am proposing for >> dREL, and make the necessary changes in dREL to make use of that alias >> information. >> >> 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 >> � � � � � � � � [email protected] >> ===================================================== >> >> On Mon, 17 Jan 2011, David Brown wrote: >> >>> Herbert, >>> >>> I had assumed that the DDLm would be backwardly compatible, but not >>> forwardly compatible.� The _alias mechanism allows a DDLm program to read >>> CIF1 and CIF2 files and store the information under DDLm names.� There may >>> be some problems with datanames that include reserved characters, but the >>> lack of a magic number at the head of the file will warn the program of >>> this >>> possibility.� Once the file is read, all the features of DDLm are >>> available.� The program can then output a CIF3 (or CIFm) file without >>> further problem. >>> >>> Whatyou want is to have the DDLm-based program write out a CIF1 or CIF2, >>> according to where it found the input or according to some other >>> instruction.� This could be done again by consulting the _aliases, but of >>> course there may not be datanames for all the items it calculates.� By >>> outputing the information under the appropriate _alias dataname, it should >>> be possible to output a CIF1 or CIF2.� The categories should take care of >>> themeselves.� The only place there would be difficulty is in the loops, >>> but >>> the DDLm rules aer stronger than the CIF1 and CIF2 rules, so the loops >>> should not violate the less stringent earler standard.� In any case I am >>> not >>> sure how your import..as would work in this mode (I would have thought an >>> export..as would be more appropriate).� The problem is that in the >>> relevant >>> items there are always two, and sometimes as many as four, _aliases which >>> means that dREL will become extremely cumbersome and would have to know >>> which _import to apply. >>> >>> But this is not really what we are talking about the moment.� If we want >>> compatiblity at the syntax level we should be worrying about the use of >>> reserved characters in the older datanames (which we have already >>> discussed), not how we should modify dREL.� It would be better to use >>> _aliases even if we have to provide information about their original >>> categories.� This is by far the cleanest place - when we are reading or >>> writing a CIF - not when we are in the middle of applying a method. >>> >>> David >>> >>> Herbert J. Bernstein wrote: >>> � � �Dear David, >>> >>> � � �� The alias mechanism in the DDLm document of 2008 does >>> � � �not seem to do the job of getting around the restrictions >>> � � �that were imposed for CIF2 on the CIF files themselves, >>> � � �invalidating basically any tag that does not conform >>> � � �to the necessities of identifer syntax in a dREL method. >>> � � �What I am proposing as a way for a dREL method itself >>> � � �to cope with an arbitrary CIF1 tag, allowing true >>> � � �CIF1 documents handled.� This is important to, for >>> � � �eaxmple, ensure that when a DDLm method is populating >>> � � �a category in a CIF1 document, that it populates the >>> � � �actual original CIF1 category and not the category >>> � � �with the CIF2 alias name.� This will allow the power >>> � � �of DDLm and dREL to be applied to documents that still >>> � � �need to be processed by existing software that is >>> � � �not yet aware of new CIF2 names for various categories >>> � � �and tags, and therefore should not automatically migrate >>> � � �to the alias name.� The current form of alias seems >>> � � �to be purely a one-way path. >>> >>> � � �� Is there a later extension of alias after the 2008 >>> � � �document? >>> >>> � � �� 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 >>> � � ����������������� [email protected] >>> � � �===================================================== >>> >>> � � �On Mon, 17 Jan 2011, David Brown wrote: >>> >>> � � � � � �This is a pssing comment on the first paragraph of >>> � � � � � �Herbert's email to set >>> � � � � � �the record straight. >>> >>> � � � � � �David Brown >>> >>> >>> >>> � � � � � �Herbert J. Bernstein wrote: >>> � � � � � ������ � What I propose is that we add one new >>> � � � � � �statement to dREL, >>> � � � � � ������ similar to the python import .. as ..., which >>> � � � � � �allows a module in >>> � � � � � ������ python that actually exists under one name to >>> � � � � � �be used in a chunk >>> � � � � � ������ of pythin code as if it had a different name. >>> � � � � � �One possible >>> � � � � � ������ syntax could be to simply extent the python >>> � � � � � �import statment >>> � � � � � ������ allowing elides in the identifier name, such >>> � � � � � �as >>> >>> � � � � � ������ � import cell\[\] as CELL >>> >>> � � � � � ������ or some other quoting mechanism to allow CIF1 >>> � � � � � �names that are not >>> � � � � � ������ valid internally in dREL to be handled by dREL >>> � � � � � �algorithms. >>> >>> � � � � � �We discussed this many moons ago.� For the most part >>> � � � � � �Herbert's suggestion is >>> � � � � � �already accommodated by the _alias feature of DDLm. >>> � � � � � �This allows any CIF1 or >>> � � � � � �CIF2 dataname to be recognized as equivalent to a >>> � � � � � �DDLm dataname at the timw >>> � � � � � �of reading.� Thus a CIF1 or CIF2 item will be >>> � � � � � �treated exactly the same way >>> � � � � � �in the program as if it were in a file written using >>> � � � � � �a DDLm dictionary. >>> � � � � � �There may be one or two places where a DDLm driven >>> � � � � � �program might have >>> � � � � � �difficulty, but they will not be common.� None come >>> � � � � � �immediately to mind. >>> � � � � � �The main problem will be trying to read the many >>> � � � � � �archived CIFs that are not >>> � � � � � �well formed, but there should be no need for a major >>> � � � � � �reformatting of the >>> � � � � � �existing archive. >>> >>> >>> � � � � � �## End of my comments >>> >>> >>> >>> � � � � � ������ � This does not mean that a DDLm dictionary >>> � � � � � �would somehow have >>> � � � � � ������ to contain the identifiers that have been >>> � � � � � �banned under CIF2. The >>> � � � � � ������ dictionary could work entirely under CIF2 >>> � � � � � �rules.� It just means >>> � � � � � ������ that the data being manipulated under control >>> � � � � � �of the dictionary >>> � � � � � ������ could include unmodified CIF1 data files and >>> � � � � � �that the algorithms >>> � � � � � ������ in dREL could be applied to the entire range >>> � � � � � �of CIF1 tags. >>> >>> � � � � � ������ � There is no import statement currently in >>> � � � � � �dREL, so there is >>> � � � � � ������ not conflict with the existing spec.� Other >>> � � � � � �than providing a >>> � � � � � ������ symbol table translation, there should be no >>> � � � � � �impact of this >>> � � � � � ������ change on the structure and syntax of dREL. >>> >>> � � � � � ������ � While this is an othogonal feature, I do >>> � � � � � �intend to also >>> � � � � � ������ propose that DDLm dictionaries we used to >>> � � � � � �process CIF1 files >>> � � � � � ������ that include CIF1-style string, e.g. the >>> � � � � � �famous 'O'', so that >>> � � � � � ������ the promise made for so many years on the IUCr >>> � � � � � �web site of being >>> � � � � � ������ able to process archived CIF1 data files with >>> � � � � � �DDLm can be kept. >>> >>> � � � � � ������ � I think CIF1 (both DDL1 and DDL2 CIF) >>> � � � � � �coupled to DDLm could be >>> � � � � � ������ a very powerful and useful combination that >>> � � � � � �could be introduced >>> � � � � � ������ with minimal disruption to existing software. >>> � � � � � �I understand that >>> � � � � � ������ others may prefer a more drastic change. I >>> � � � � � �hope they will see >>> � � � � � ������ the value in allowing this more cautious and >>> � � � � � �conservative >>> � � � � � ������ approach to go forward under the CIF banner, >>> � � � � � �even if they >>> � � � � � ������ themselves intend to pursue their own, more >>> � � � � � �drastic set of >>> � � � � � ������ changes, also under the CIF banner. >>> >>> � � � � � ������ � If this is agreeable, I will undertake to >>> � � � � � �have a demonstration >>> � � � � � ������ version of DDLm/dREL fully coupled to CIF1 >>> � � � � � �using the import ... >>> � � � � � ������ as ... statement to show and discuss with >>> � � � � � �those who are >>> � � � � � ������ interested in Madrid. >>> >>> � � � � � ������ � 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 >>> � � � � � ������ ���������������� [email protected] >>> >>> � � � � � �===================================================== >>> >>> � � � � � ������ On Sun, 16 Jan 2011, Herbert J. Bernstein >>> � � � � � �wrote: >>> >>> � � � � � ������������ Dear Simon, >>> >>> � � � � � ������������ �If I read your message correctly, you >>> � � � � � �seem to be >>> � � � � � ������������ saying that the design objectives of >>> � � � � � �CIF2 are: >>> >>> � � � � � ������������ �1.� enchance CIF as a data source >>> � � � � � ������������ �2.� accomodate DDLm >>> � � � � � ������������ �3.� do 1 and 2 in a way that does not >>> � � � � � �complicate >>> � � � � � ������������ CIF as a data source >>> >>> � � � � � ������������ �I don't understand what you mean by >>> � � � � � �"enhance CIF as >>> � � � � � ������������ a data source". This is the first time I >>> � � � � � �recall >>> � � � � � ������������ hearing that objective.� Please clarify. >>> >>> � � � � � ������������ In terms of present practice, I had >>> � � � � � �thought that the >>> � � � � � ������������ major current uses of CIF to be: >>> >>> � � � � � ������������ �1.� As a language for publication of >>> � � � � � �papers in IUCr >>> � � � � � ������������ journals; >>> � � � � � ������������ �2.� As a language for submission of >>> � � � � � �data to CCDC; >>> � � � � � ������������ �3.� As a language for submission of >>> � � � � � �data to the >>> � � � � � ������������ PDB; >>> � � � � � ������������ �4.� As a data harvest language for >>> � � � � � �CCP4; and >>> � � � � � ������������ �5.� As a language for formatting image >>> � � � � � �data from >>> � � � � � ������������ Dectris detectors, >>> � � � � � ������������ with some emerging use for data >>> � � � � � �management of >>> � � � � � ������������ synchrotron data >>> � � � � � ������������ �( Please fill in uses I have missed >>> � � � � � �...) >>> >>> � � � � � ������������ which would seem to me to represent a >>> � � � � � �large current >>> � � � � � ������������ investment in data management software >>> � � � � � �that depends >>> � � � � � ������������ critically on stability and reliability >>> � � � � � �of CIF >>> � � � � � ������������ representation of both numeric data and >>> � � � � � �text.� As I >>> � � � � � ������������ understand it, DDLm and dREL can >>> � � � � � �contribute to these >>> � � � � � ������������ current uses by enhancing the reliabiity >>> � � � � � �of >>> � � � � � ������������ validation of data in these contexts, >>> � � � � � �especially in >>> � � � � � ������������ uses 1, 2 and 3, above. To me, that >>> � � � � � �would� seem to >>> � � � � � ������������ change the objectives to: >>> >>> � � � � � ������������ �1.� Accomodate DDLm and dREL; and >>> � � � � � ������������ �2.� Do this in a way that keeps >>> � � � � � �required changes to >>> � � � � � ������������ existing >>> � � � � � ������������ archives to a minimum; and >>> � � � � � ������������ �3.� Do this in a way that allows as >>> � � � � � �much existing >>> � � � � � ������������ CIF software >>> � � � � � ������������ as possible to continue to operate >>> � � � � � �reliably; and >>> � � � � � ������������ �4.� To the extent that changes will be >>> � � � � � �needed in >>> � � � � � ������������ archives and >>> � � � � � ������������ software, provide a clearly understood >>> � � � � � �mechanism for >>> � � � � � ������������ making >>> � � � � � ������������ those changes, with as much support >>> � � � � � �software as >>> � � � � � ������������ possible; and >>> � � � � � ������������ �5.� Subordinate to the above, add new >>> � � � � � �features to >>> � � � � � ������������ CIF that may >>> � � � � � ������������ encourage broader use and more software >>> � � � � � �support >>> >>> � � � � � ������������ Please tell me what I have misunderstood >>> � � � � � �in this. >>> >>> � � � � � ������������ 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 >>> � � � � � ������������ ��������������� [email protected] >>> >>> � � � � � �===================================================== >>> >>> � � � � � ������������ On Sun, 16 Jan 2011, SIMON WESTRIP >>> � � � � � �wrote: >>> >>> � � � � � ������������������ I believe that the CIF2 syntax >>> � � � � � �changes >>> � � � � � ������������������ enhance CIF as data source, >>> � � � � � ������������������ even with the restriction to the >>> � � � � � ������������������ contents of� ' and " delimited >>> � � � � � �values, >>> � � � � � ������������������ which >>> � � � � � ������������������ I suspect will be the main source >>> � � � � � �of >>> � � � � � ������������������ incompatability between archived >>> � � � � � �CIFs >>> � � � � � ������������������ and CIF2. What we havent acheived >>> � � � � � �is >>> � � � � � ������������������ 100% compatability of CIF1 with >>> � � � � � �CIF2, >>> � � � � � ������������������ but having agreed that CIF2 is >>> � � � � � �distinct >>> � � � � � ������������������ from CIF1 and minimized the >>> � � � � � ������������������ incompatability, >>> � � � � � ������������������ I do not see the changes as >>> � � � � � �disruptive >>> � � � � � ������������������ or retrograde. >>> >>> � � � � � ������������������ DDLm methods will not be >>> � � � � � �applicable to a >>> � � � � � ������������������ significant percentage of a CIF >>> � � � � � ������������������ data source >>> � � � � � ������������������ (those 'free text' fields used to >>> � � � � � �report >>> � � � � � ������������������ experimental details etc.). I >>> � � � � � ������������������ believe other approaches >>> � � � � � ������������������ will be needed to enhance their >>> � � � � � �content >>> � � � � � ������������������ (referencing other data items from >>> � � � � � ������������������ an item etc). >>> � � � � � ������������������ Unicode support in CIF2 is >>> � � � � � �beneficial in >>> � � � � � ������������������ this area, and the new alternative >>> � � � � � ������������������ delimiters may >>> � � � � � ������������������ prove convenient. The list and >>> � � � � � �table >>> � � � � � ������������������ structures may also be exploited. >>> >>> � � � � � ������������������ So from my point of view, though I >>> � � � � � ������������������ understood the aim of CIF2 was to >>> � � � � � ������������������ accommodate DDLm, >>> � � � � � ������������������ it turns out that it does offer a >>> � � � � � �little >>> � � � � � ������������������ bit more. I would still like the >>> � � � � � ������������������ problem of including all >>> � � � � � �delimiters >>> � � � � � ������������������ in a value to be solved, and >>> � � � � � ������������������ line-folding to be included. On my >>> � � � � � �'wish >>> � � � � � ������������������ list' >>> � � � � � ������������������ are value concatenation >>> � � � � � ������������������ and a value-referencing mechanism >>> � � � � � �for >>> � � � � � ������������������ use with CIF as a data source. >>> >>> � � � � � ������������������ I know this doesnt really answer >>> � � � � � �your >>> � � � � � ������������������ question. What we are *not* trying >>> � � � � � �to >>> � � � � � ������������������ do is complicate >>> � � � � � ������������������ �CIF as a data source? >>> >>> � � � � � ������������������ Cheers >>> >>> � � � � � ������������������ Simon >>> >>> >>> ___________________________________________________________________________ >>> >>> � � � � � ������������������ _ >>> � � � � � ������������������ From: Herbert J. Bernstein >>> � � � � � ������������������ <[email protected]> >>> � � � � � ������������������ To: Group finalising DDLm and >>> � � � � � �associated >>> � � � � � ������������������ dictionaries <[email protected]> >>> � � � � � ������������������ Sent: Sunday, 16 January, 2011 >>> � � � � � �2:05:59 >>> � � � � � ������������������ Subject: Re: [ddlm-group] >>> � � � � � �Relationship >>> � � � � � ������������������ asmong CIF2, STAR, CIF1 and >>> � � � � � �Python. . >>> >>> � � � � � ������������������ Dear Simon, >>> >>> � � � � � ������������������ � I have reviewed the record on >>> � � � � � �this, >>> � � � � � ������������������ and I have trouble finding >>> � � � � � ������������������ a strong basis for most of the >>> � � � � � �decisions >>> � � � � � ������������������ made other than arguments >>> � � � � � ������������������ from the authority of established >>> � � � � � �past >>> � � � � � ������������������ practice in STAR and dREL. >>> � � � � � ������������������ Now that those arguments have >>> � � � � � �turned out >>> � � � � � ������������������ not to have been what they >>> � � � � � ������������������ seemed, I have trouble accepting >>> � � � � � �the >>> � � � � � ������������������ resulting conclusions without >>> � � � � � ������������������ new, clearly stated arguments >>> � � � � � �based in >>> � � � � � ������������������ the functionality we are >>> � � � � � ������������������ trying to achieve, but it is now >>> � � � � � �not >>> � � � � � ������������������ even clear what functionality we >>> � � � � � ������������������ are >>> � � � � � ������������������ trying to achieve. >>> >>> � � � � � ������������������ � Perhaps you can help me -- what >>> � � � � � �are we >>> � � � � � ������������������ trying to do in defining >>> � � � � � ������������������ CIF2? >>> >>> � � � � � ������������������ � Regards, >>> � � � � � ������������������ � � Herbert >>> >>> >>> � � � � � ������������������ At 11:55 PM +0000 1/15/11, SIMON >>> � � � � � �WESTRIP >>> � � � � � ������������������ wrote: >>> � � � � � ������������������ >That's a question I asked myself >>> � � � � � �when I >>> � � � � � ������������������ first joined this discussion group >>> � � � � � ������������������ :-) >>> � � � � � ������������������ > >>> � � � � � ������������������ >To be honest Herbert, I do not >>> � � � � � �feal >>> � � � � � ������������������ qualified to contest anything to >>> � � � � � �do >>> � � � � � ������������������ with >>> � � � � � ������������������ >dREL, nor DDLm, given that I >>> � � � � � �havent >>> � � � � � ������������������ worked on them and respecting the >>> � � � � � ������������������ >years of effort that went into >>> � � � � � ������������������ development thus far. The same is >>> � � � � � ������������������ >true with respect to some of >>> � � � � � ������������������ >the changes to CIF syntax that >>> � � � � � ������������������ invalidate CIF1: I have accepted >>> � � � � � �that >>> � � � � � ������������������ >they are necessary >>> � � � � � ������������������ >to facilitate implementation of >>> � � � � � �dREL >>> � � � � � ������������������ methods. >>> � � � � � ������������������ > >>> � � � � � ������������������ >Cheers >>> � � � � � ������������������ > >>> � � � � � ������������������ >Simon >>> � � � � � ������������������ > >>> � � � � � ������������������ > >>> � � � � � ������������������ > >>> � � � � � ������������������ >From: Herbert J. Bernstein >>> � � � � � ������������������ <[email protected]> >>> � � � � � ������������������ >To: Group finalising DDLm and >>> � � � � � ������������������ associated dictionaries >>> � � � � � ������������������ <[email protected]> >>> � � � � � ������������������ >Sent: Saturday, 15 January, 2011 >>> � � � � � ������������������ 23:14:36 >>> � � � � � ������������������ >Subject: Re: [ddlm-group] >>> � � � � � �Relationship >>> � � � � � ������������������ asmong CIF2, STAR, CIF1 and >>> � � � � � �Python. >>> � � � � � ������������������ . >>> � � � � � ������������������ > >>> � � � � � ������������������ >Why not?� It is almost that right >>> � � � � � �now. >>> � � � � � ������������������ > >>> � � � � � ������������������ > >>> � � � � � ������������������ >At 11:08 PM +0000 1/15/11, SIMON >>> � � � � � ������������������ WESTRIP wrote: >>> � � � � � ������������������ >>True - but I can't see dREL >>> � � � � � �becoming >>> � � � � � ������������������ pyREL at this stage? >>> � � � � � ������������������ >> >>> � � � � � ������������������ >> >>> � � � � � ������������������ >> >>> � � � � � ������������������ >>From: Herbert J. Bernstein >>> >>> >>> �>><<mailto:[email protected]>[email protected]> >>> � � � � � ������������������ >>To: Group finalising DDLm and >>> � � � � � ������������������ associated dictionaries >>> >>> � � � � � �>><<mailto:[email protected]>[email protected]> >>> � � � � � ������������������ >>Sent: Saturday, 15 January, 2011 >>> � � � � � ������������������ 22:57:17 >>> � � � � � ������������������ >>Subject: Re: [ddlm-group] >>> � � � � � �Relationship >>> � � � � � ������������������ asmong CIF2, STAR, CIF1 and >>> � � � � � �Python. >>> � � � � � ������������������ . >>> � � � � � ������������������ >> >>> � � � � � ������������������ >>Dear Simon, >>> � � � � � ������������������ >> >>> � � � � � ������������������ >>� But dREL already shares much >>> � � � � � �of >>> � � � � � ������������������ Python syntax and data structures, >>> � � � � � ������������������ >>but, being significantly >>> � � � � � �mutated, >>> � � � � � ������������������ lacks the software support and >>> � � � � � ������������������ >>documentation that Python has. >>> � � � � � �Anyone >>> � � � � � ������������������ who has to work with the >>> � � � � � ������������������ >>methods in a DDLm dictionary >>> � � � � � �would be >>> � � � � � ������������������ much better off if we >>> � � � � � ������������������ >>simply made Python work with >>> � � � � � �DDLm.� We >>> � � � � � ������������������ would gain large libraries >>> � � � � � ������������������ >>of pre-written utilities, tools >>> � � � � � �to >>> � � � � � ������������������ test code fragments interactively, >>> � � � � � ������������������ >>and a lot more time to do >>> � � � � � �science or >>> � � � � � ������������������ whatever we are actually >>> � � � � � ������������������ >>funded to do. >>> � � � � � ������������������ >> >>> � � � � � ������������������ >>� Regards, >>> � � � � � ������������������ >>� � Herbert >>> � � � � � ������������������ >> >>> � � � � � ������������������ >> >>> � � � � � ������������������ >> >>> � � � � � ������������������ >>At 10:35 PM +0000 1/15/11, SIMON >>> � � � � � ������������������ WESTRIP wrote: >>> � � � � � ������������������ >>>As far as I can see, parsing >>> � � � � � �DDLm >>> � � � � � ������������������ into an object stucture is fairly >>> � � � � � ������������������ >>>uncomplicated; >>> � � � � � ������������������ >>>the hurdle is parsing the dREL >>> � � � � � �script >>> � � � � � ������������������ as a method of the object. >>> � � � � � ������������������ >>>Unless working with python, I'm >>> � � � � � �not >>> � � � � � ������������������ sure that adopting python syntax >>> � � � � � ������������������ >>>for DDLm/CIF >>> � � � � � ������������������ >>>is of any great benefit; >>> � � � � � �likewise for >>> � � � � � ������������������ dREL. >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>That said, I have yet to >>> � � � � � �actually do >>> � � � � � ������������������ anything with DDLm, let alone >>> � � � � � ������������������ >>>dREL, so I may be >>> � � � � � ������������������ >>>well off the mark. But even if >>> � � � � � �this >>> � � � � � ������������������ is the case, I suspect there >>> � � � � � ������������������ >>>will be non-python programmers >>> � � � � � �out >>> � � � � � ������������������ >>>there that have cause to work >>> � � � � � �with >>> � � � � � ������������������ CIF and similarly will see no >>> � � � � � ������������������ >>>obvious benefit in >>> � � � � � ������������������ >>>CIF sharing python syntax >>> � � � � � �(especially >>> � � � � � ������������������ if it only adopts it for one >>> � � � � � ������������������ >>>set of delimiters at the >>> � � � � � ������������������ >>>data-source level). >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>Cheers >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>Simon >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>From: Herbert J. Bernstein >>> >>>>>>>>> <<mailto:<mailto:[email protected]>[email protected] >>> >>> >>> >>> >>> �om><mailto:[email protected]>[email protected]> >>> � � � � � ������������������ >>>To: Group finalising DDLm and >>> � � � � � ������������������ associated dictionaries >>> >>>>>>>>> <<mailto:<mailto:[email protected]>[email protected]><mailto:ddlm-gr >>> >>> >>> � � � � � ������������������ [email protected]>[email protected]> >>> � � � � � ������������������ >>>Sent: Saturday, 15 January, >>> � � � � � �2011 >>> � � � � � ������������������ 21:16:59 >>> � � � � � ������������������ >>>Subject: Re: [ddlm-group] >>> � � � � � ������������������ Relationship asmong CIF2, STAR, >>> � � � � � �CIF1 and >>> � � � � � ������������������ Python. . >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>At 12:43 PM +0000 1/15/11, >>> � � � � � �Brian >>> � � � � � ������������������ McMahon wrote: >>> � � � � � ������������������ >>>>It might be worth remarking >>> � � � � � �(again) >>> � � � � � ������������������ that dREL is being developed as a >>> � � � � � ������������������ >>>>canonical methods description >>> � � � � � ������������������ language, and not necessarily the >>> � � � � � ������������������ runtime >>> � � � � � ������������������ >� >>>methods evaluator of choice >>> � � � � � �for >>> � � � � � ������������������ future applications. It may be >>> � � � � � �that in >>> � � � � � ������������������ >>>>practice future methods are >>> � � � � � ������������������ initially developed and most >>> � � � � � �frequently >>> � � � � � ������������������ >>>>executed directly in Python or >>> � � � � � �some >>> � � � � � ������������������ other language. As I see it, the >>> � � � � � ������������������ >>>>goal of CIF and DDL evolution >>> � � � � � �is not >>> � � � � � ������������������ to exclude such a possibility. >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>If we are trying to be Python >>> � � � � � ������������������ friendly and much of dREL is >>> � � � � � �derived >>> � � � � � ������������������ >>>from a Jython implementation, I >>> � � � � � �don't >>> � � � � � ������������������ understand why we are not >>> � � � � � ������������������ >>>conforming dREL, DDLm and CIF2 >>> � � � � � �to >>> � � � � � ������������������ Python conventions as closely as >>> � � � � � ������������������ >>>possible. >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>> >>> � � � � � ������������������ >>>At 12:43 PM +0000 1/15/11, >>> � � � � � �Brian >>> � � � � � ������������������ McMahon wrote: >>> � � � � � ������������������ >>>>On Thu, Jan 13, 2011 at >>> � � � � � �05:35:21PM >>> � � � � � ������������������ -0600, Bollinger, John C wrote: >>> � � � � � ������������������ >>>>> >>> � � � � � ������������������ >>>>>� (snip) >>> � � � � � ������������������ >>>>> >>> � � � � � ������������������ >>>>>� CIF2 <=> CIF1: >>> � � � � � ������������������ >>>>>� To the greatest extent >>> � � � � � �feasible, >>> � � � � � ������������������ well-formed CIF1 documents should >>> � � � � � �be >>> � � � � � ������������������ >>>>>� well-formed CIF2 documents >>> � � � � � ������������������ (modulo a CIF version >>> � � � � � �identification >>> � � � � � ������������������ >>>>>� signature) having the same >>> � � � � � ������������������ meaning. >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>Agreed. >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>>� CIF2 <=> STAR: >>> � � � � � ������������������ >>>>>� Inasmuch as CIF1 is derived >>> � � � � � �from >>> � � � � � ������������������ STAR, I think it appropriate for >>> � � � � � ������������������ CIF2 >>> � � � � � ������������������ >>>>>� to look first to STAR, >>> � � � � � �including >>> � � � � � ������������������ its post-CIF1 development, for new >>> � � � � � ������������������ >>>>>� features it may need.� Even >>> � � � � � �if >>> � � � � � ������������������ CIF2 is not 100% compatible with >>> � � � � � �STAR, >>> � � � � � ������������������ it >>> � � � � � ������������������ >>>>>� is worthwhile to avoid >>> � � � � � �diverging >>> � � � � � ������������������ without compelling reason. >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>Agreed >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>>� CIF2 <=> Python: >>> � � � � � ������������������ >>>>>� I see no particular reason >>> � � � � � �for >>> � � � � � ������������������ any formal relationship here >>> � � � � � �beyond >>> � � � � � ������������������ >>>>>� Python's role as the >>> � � � � � �indirect >>> � � � � � ������������������ inspiration for CIF2's new >>> � � � � � ������������������ >>>>>� triple-quote syntax.� I am >>> � � � � � �wary >>> � � � � � ������������������ of the idea of tying CIF tightly >>> � � � � � �to >>> � � � � � ������������������ >>>>>� a particular language. >>> � � � � � �CIF2 >>> � � � � � ������������������ documents are not and never will >>> � � � � � �be >>> � � � � � ������������������ >>>>>� Python programs.� I could >>> � � � � � �imagine >>> � � � � � ������������������ embedding Python in CIF or vise >>> � � � � � ������������������ >>� >>>� versa, but I have seen no >>> � � � � � ������������������ evidence to suggest that greater >>> � � � � � ������������������ similarity >>> � � � � � ������������������ >>>>>� between the two languages' >>> � � � � � �syntax >>> � � � � � ������������������ and semantics would benefit >>> � � � � � �efforts >>> � � � � � ������������������ >>>>>� such as those. >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>Agreed. As I mention >>> � � � � � �elsewhere, >>> � � � � � ������������������ there is a greater influence on >>> � � � � � �the >>> � � � � � ������������������ >>>>prototype dREL (arising from >>> � � � � � �the >>> � � � � � ������������������ initial Jython implementation), >>> � � � � � �and >>> � � � � � ������������������ >>>>the list and table data types >>> � � � � � ������������������ doubtless arise from that also. >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>It might be worth remarking >>> � � � � � �(again) >>> � � � � � ������������������ that dREL is being developed as a >>> � � � � � ������������������ >>>>canonical methods description >>> � � � � � ������������������ language, and not necessarily the >>> � � � � � ������������������ runtime >>> � � � � � ������������������ >>>>methods evaluator of choice >>> � � � � � �for >>> � � � � � ������������������ future applications. It may be >>> � � � � � �that in >>> � � � � � ������������������ >>>� >practice future methods are >>> � � � � � ������������������ initially developed and most >>> � � � � � �frequently >>> � � � � � ������������������ >>>>executed directly in Python or >>> � � � � � �some >>> � � � � � ������������������ other language. As I see it, the >>> � � � � � ������������������ >>>>goal of CIF and DDL evolution >>> � � � � � �is not >>> � � � � � ������������������ to exclude such a possibility. >>> � � � � � ������������������ >>>> >>> � � � � � ������������������ >>>>Regards >>> � � � � � ������������������ >>>>Brian >>> >>> � � � � � �>>>>_______________________________________________ >>> � � � � � ������������������ >>>>ddlm-group mailing list >>> >>>>>>>>>>> <mailto:<mailto:<mailto:[email protected]>[email protected]><mailto >>> >>> >>> >>> :[email protected]>[email protected]><mailto:<mailto:[email protected] >>> >>> >>> >>> >>> �g>[email protected]><mailto:[email protected]>[email protected] >>> >>>>>>>>>>> <<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.i >>> >>> >>> >>> ucr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listin >>> >>> >>> >>> fo/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http:// >>> >>> >>> >>> scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailma >>> >>> >>> >>> n/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group> >>> >>> >>> >>> � � � � � �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 >>> � � � � � ������������������ >>> >>> >>>>>>>>> <mailto:<mailto:<mailto:[email protected]>[email protected]><mailto:yaya@d >>> >>> >>> >>> owling.edu>[email protected]><mailto:<mailto:[email protected]>[email protected] >>> >>> >>> >>> � � � � � �du><mailto:[email protected]>[email protected] >>> >>> � � � � � �>>>===================================================== >>> >>> � � � � � �>>>_______________________________________________ >>> � � � � � ������������������ >>>ddlm-group mailing list >>> >>>>>>>>> <mailto:<mailto:<mailto:[email protected]>[email protected]><mailto: >>> >>> >>> >>> [email protected]>[email protected]><mailto:<mailto:[email protected] >>> >>> >>> >>> >>> �>[email protected]><mailto:[email protected]>[email protected] >>> >>>>>>>>> <<<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iu >>> >>> >>> >>> cr.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinf >>> >>> >>> >>> o/ddlm-group>http://scripts.iucr.org/mailman/listinfo/ddlm-group><<http://s >>> >>> >>> >>> cripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.org/mailman >>> >>> >>> >>> /listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo/ddlm-group>h >>> >>> >>> >>> � � � � � �ttp://scripts.iucr.org/mailman/listinfo/ddlm-group >>> � � � � � ������������������ >� >> >>> � � � � � ������������������ >>> >>> >>> � � � � � �>>>_______________________________________________ >>> � � � � � ������������������ >>>ddlm-group mailing list >>> >>>>>>>>> <mailto:<mailto:[email protected]>[email protected]><mailto:ddlm-gro >>> >>> >>> � � � � � ������������������ [email protected]>[email protected] >>> >>>>>>>>> <<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iuc >>> >>> >>> >>> r.org/mailman/listinfo/ddlm-group><http://scripts.iucr.org/mailman/listinfo >>> >>> >>> >>> � � � � � �/ddlm-group>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 >>> � � � � � ������������������ >> >>> >>>>>>> <mailto:<mailto:[email protected]>[email protected]><mailto:[email protected] >>> >>> >>> � � � � � ������������������ u>[email protected] >>> >>> � � � � � �>>===================================================== >>> >>> � � � � � �>>_______________________________________________ >>> � � � � � ������������������ >>ddlm-group mailing list >>> >>>>>>> <mailto:<mailto:[email protected]>[email protected]><mailto:ddlm-grou >>> >>> >>> � � � � � ������������������ [email protected]>[email protected] >>> >>>>>>> <<http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr >>> >>> >>> >>> .org/mailman/listinfo/ddlm-group><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 >>> � � � � � ������������������ > >>> � � � � � ������������������ > >>> � � � � � ������������������ >-- >>> >>> � � � � � �>===================================================== >>> � � � � � ������������������ >� 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] >>> >>> � � � � � �>===================================================== >>> >>> � � � � � �>_______________________________________________ >>> � � � � � ������������������ >ddlm-group mailing list >>> >>> � � � � � �><mailto:[email protected]>[email protected] >>> >>>>> <http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.o >>> >>> >>> � � � � � ������������������ rg/mailman/listinfo/ddlm-group >>> � � � � � ������������������ > >>> � � � � � ������������������ > >>> >>> � � � � � �>_______________________________________________ >>> � � � � � ������������������ >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 >>> >>> >>> >>> >>> �____________________________________________________________________ >>> >>> � � � � � �_______________________________________________ >>> � � � � � �ddlm-group mailing list >>> � � � � � �[email protected] >>> � � � � � �http://scripts.iucr.org/mailman/listinfo/ddlm-group >>> >>> >>> >>> >>> >>> � �____________________________________________________________________ >>> >>> _______________________________________________ >>> ddlm-group mailing list >>> [email protected] >>> http://scripts.iucr.org/mailman/listinfo/ddlm-group >>> >>> >>> >>> >> >> _______________________________________________ >> ddlm-group mailing list >> [email protected] >> 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 >
_______________________________________________ ddlm-group mailing list [email protected] http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. . (Herbert J. Bernstein)
- References:
- 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. . (Brian McMahon)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (SIMON WESTRIP)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (SIMON WESTRIP)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (SIMON WESTRIP)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (SIMON WESTRIP)
- 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)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (David Brown)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (Herbert J. Bernstein)
- Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. . (David Brown)
- 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)
- 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):