[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ddlm-group] Relationship asmong CIF2, STAR,CIF1 and Python. .

If we are trying to ensure that "a well-formed CIF1 documents should be
well-formed CIF2 documents (modulo a CIF version identification
signature) having the same meaning," then why have we invalidated
a large number of existing CIF1 documents in CIF2?

We really do need to establish the premises of this exercise.

Are we trying to ensure that all CIF1 documents will be CIF2
documents or not?

If our goal is more limited, then precisely which types of CIF1
documents are we planning to exclude and who is responsible for
translating them to CIF2?

Few systems are perfectly consistent with their stated goals, but
CIF2 as it now stands seems remarkably inconsistent with its publicly
stated goals.  If we are not going to fix CIF2 then in the spirit
of delcaring "that is not a bug, it is  feature," we should at
least coherently restate our goals to remove the conflicts.



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
>ddlm-group@iucr.org
>http://scripts.iucr.org/mailman/listinfo/ddlm-group


-- 
=====================================================
  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769

                  +1-631-244-3035
                  yaya@dowling.edu
=====================================================
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

Reply to: [list | sender only]