[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
- To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
- Subject: Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Tue, 18 Jan 2011 05:55:08 -0500 (EST)
- In-Reply-To: <AANLkTikHMgQy=dyPBGR2vmBkZ2EMRgfYiTyqnZ+-x8ZN@mail.gmail.com>
- References: <alpine.BSF.2.00.1101120536370.71134@epsilon.pair.com><698308.91583.qm@web87015.mail.ird.yahoo.com><alpine.BSF.2.00.1101121845060.90622@epsilon.pair.com><alpine.BSF.2.00.1101131202050.27153@epsilon.pair.com><20110115124309.GC238@emerald.iucr.org><a06240800c957bd6d16ee@192.168.2.102><852149.16036.qm@web87006.mail.ird.yahoo.com><a06240800c957d517a29e@192.168.2.102><102605.32946.qm@web87004.mail.ird.yahoo.com><a06240802c957da53dcb4@192.168.2.102><878774.52502.qm@web87007.mail.ird.yahoo.com><a06240803c95801a71470@192.168.2.102><917746.19637.qm@web87007.mail.ird.yahoo.com><alpine.BSF.2.00.1101160651520.88418@epsilon.pair.com><alpine.BSF.2.00.1101160855300.88418@epsilon.pair.com><4D3473CA.1050507@mcmaster.ca><alpine.BSF.2.00.1101171406330.84073@epsilon.pair.com><4D34AE67.2020502@mcmaster.ca><alpine.BSF.2.00.1101171838340.33692@epsilon.pair.com><AANLkTikHMgQy=dyPBGR2vmBkZ2EMRgfYiTyqnZ+-x8ZN@mail.gmail.com>
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
yaya@dowling.edu
=====================================================
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
> <yaya@bernstein-plus-sons.com> 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
>> yaya@dowling.edu
>> =====================================================
>>
>> 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
>>> yaya@dowling.edu
>>> =====================================================
>>>
>>> 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
>>> yaya@dowling.edu
>>>
>>> =====================================================
>>>
>>> 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
>>> yaya@dowling.edu
>>>
>>> =====================================================
>>>
>>> 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
>>> <yaya@bernstein-plus-sons.com>
>>> To: Group finalising DDLm and
>>> associated
>>> dictionaries <ddlm-group@iucr.org>
>>> 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
>>> <yaya@bernstein-plus-sons.com>
>>> >To: Group finalising DDLm and
>>> associated dictionaries
>>> <ddlm-group@iucr.org>
>>> >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:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>>> >>To: Group finalising DDLm and
>>> associated dictionaries
>>>
>>> >><<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org>
>>> >>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:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.c
>>>
>>>
>>>
>>>
>>> om><mailto:yaya@bernstein-plus-sons.com>yaya@bernstein-plus-sons.com>
>>> >>>To: Group finalising DDLm and
>>> associated dictionaries
>>>
>>>>>>>>> <<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-gr
>>>
>>>
>>> oup@iucr.org>ddlm-group@iucr.org>
>>> >>>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:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto
>>>
>>>
>>>
>>> :ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.or
>>>
>>>
>>>
>>>
>>> g>ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>
>>>>>>>>>>> <<<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:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@d
>>>
>>>
>>>
>>> owling.edu>yaya@dowling.edu><mailto:<mailto:yaya@dowling.edu>yaya@dowling.e
>>>
>>>
>>>
>>> du><mailto:yaya@dowling.edu>yaya@dowling.edu
>>>
>>> >>>=====================================================
>>>
>>> >>>_______________________________________________
>>> >>>ddlm-group mailing list
>>>
>>>>>>>>> <mailto:<mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:
>>>
>>>
>>>
>>> ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:<mailto:ddlm-group@iucr.org
>>>
>>>
>>>
>>>
>>> >ddlm-group@iucr.org><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>
>>>>>>>>> <<<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:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-gro
>>>
>>>
>>> up@iucr.org>ddlm-group@iucr.org
>>>
>>>>>>>>> <<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:yaya@dowling.edu>yaya@dowling.edu><mailto:yaya@dowling.ed
>>>
>>>
>>> u>yaya@dowling.edu
>>>
>>> >>=====================================================
>>>
>>> >>_______________________________________________
>>> >>ddlm-group mailing list
>>>
>>>>>>> <mailto:<mailto:ddlm-group@iucr.org>ddlm-group@iucr.org><mailto:ddlm-grou
>>>
>>>
>>> p@iucr.org>ddlm-group@iucr.org
>>>
>>>>>>> <<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:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>
>>>>>>> <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:yaya@dowling.edu>yaya@dowling.edu
>>>
>>> >=====================================================
>>>
>>> >_______________________________________________
>>> >ddlm-group mailing list
>>>
>>> ><mailto:ddlm-group@iucr.org>ddlm-group@iucr.org
>>>
>>>>> <http://scripts.iucr.org/mailman/listinfo/ddlm-group>http://scripts.iucr.o
>>>
>>>
>>> rg/mailman/listinfo/ddlm-group
>>> >
>>> >
>>>
>>> >_______________________________________________
>>> >ddlm-group mailing list
>>> >ddlm-group@iucr.org
>>>
>>> >http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>>
>>> --
>>>
>>> =====================================================
>>> Herbert J. Bernstein, Professor
>>> of
>>> Computer Science
>>> Dowling College, Kramer
>>> Science
>>> Center, KSC 121
>>> Idle Hour Blvd, Oakdale,
>>> NY,
>>> 11769
>>>
>>> +1-631-244-3035
>>> yaya@dowling.edu
>>>
>>> =====================================================
>>>
>>> _______________________________________________
>>> ddlm-group mailing list
>>> ddlm-group@iucr.org
>>>
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>>
>>>
>>>
>>> ____________________________________________________________________
>>>
>>> _______________________________________________
>>> ddlm-group mailing list
>>> ddlm-group@iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>>
>>>
>>>
>>>
>>> ____________________________________________________________________
>>>
>>> _______________________________________________
>>> ddlm-group mailing list
>>> ddlm-group@iucr.org
>>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> ddlm-group mailing list
>> ddlm-group@iucr.org
>> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>>
>>
>
>
>
> --
> T +61 (02) 9717 9907
> F +61 (02) 9717 3145
> M +61 (04) 0249 4148
> _______________________________________________
> ddlm-group mailing list
> ddlm-group@iucr.org
> http://scripts.iucr.org/mailman/listinfo/ddlm-group
>
_______________________________________________ ddlm-group mailing list ddlm-group@iucr.org 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):