Discussion List Archives

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

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

I'm frankly not entirely sure why people are exercised about STAR
compatibility.  Perhaps Simon and Herbert could explain why small
syntactical differences are such a big deal?  While I am in favour of
keeping the essential STAR philosophy ("a syntactical container for
data") and maintaining compatibility in abstract datastructures, I
don't see why CIF can't stand on its own legs.  Why is anybody spooked
by the thought that CIF might parse certain vanishingly rare strings
in a different way to STAR?

I note that none of my objections to the Python elide proposal have
anything to do with STAR.

On Fri, Jan 14, 2011 at 11:15 AM, SIMON WESTRIP
<[email protected]> wrote:
>> that the CIF2 syntax we had been discussing was a compatible subset of an
>> as-yet unpublished updated version of STAR
>
> This was my assumption.
>
>>I now find that this is not exactly the case...
>
> This is disappointing to say the least.
>
>
>
> ________________________________
> From: "Bollinger, John C" <[email protected]>
> To: Group finalising DDLm and associated dictionaries <[email protected]>
> Sent: Thursday, 13 January, 2011 23:35:21
> Subject: Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
>
>
> On Thursday, January 13, 2011 11:18 AM, Herbert J. Bernstein wrote:
>>[...] it has become clear to me that I was
>>making false assumptions about the relationship between
>>CIF2 and STAR.� I believe that a zero-based discussion is
>>now needed on what the relationship should be among CIF2,
>>STAR, CIF1 and Python to best serve the interests
>>of the crystallographic community.� I do not know what
>>is best and do not know how long such a discussion may take.
>>I leave it to James, Nick and Brian to decide if Nick's and
>>Brian's messages should be posted on this list for the record.
>
> Indeed, I find that I, too, was making false assumptions about the
> relationship between CIF2 and STAR.� In particular, I mistakenly believed
> that the CIF2 syntax we had been discussing was a compatible subset of an
> as-yet unpublished updated version of STAR.� I now find that this is not
> exactly the case, at least in that the STAR update now being prepared for
> publication includes a minimal set of string delimiter elides that CIF2 does
> not contain, thus rendering the two incompatible (some well-formed CIF2
> files would not be well-formed STAR files).� As I understand it, these
> elides apply to single-quoted strings and to one form of triple-quoted
> string, using approximately \<delimiter> as the elide.
>
> I'm not entirely sure what would be a "zero-based discussion [...] on what
> the relationship should be among CIF2, STAR, CIF1 and Python to best serve
> the interests of the crystallographic community."� As for what the
> relationship *is*, though, my analysis of CIF1.1 and STAR1, as published in
> ITG, is that all documents conforming to the CIF1.1 syntax also conform to
> the STAR1 syntax, EXCEPT those that contain at least one data block without
> any data in it.� (Empty data blocks are allowed in CIF, but not in STAR1.)
>
> As for what the relationships should be, all we can influence is the
> relationships between CIF2 and the others.� I think they should be something
> like this:
>
> 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.
>
> 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.
>
> 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.
>
>
> Regards,
>
> John
>
> --
> John C. Bollinger, Ph.D.
> Department of Structural Biology
> St. Jude Children's Research Hospital
>
>
> Email Disclaimer:� www.stjude.org/emaildisclaimer
>
> _______________________________________________
> ddlm-group mailing list
> [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

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links