[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):

