Discussion List Archives

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

Re: [ddlm-group] Simon's elide proposal

Dear Herbert,

On Friday, January 14, 2011 4:26 AM, Herbert J. Bernstein wrote:
>   1.  I do think there is value in having CIF capable for functioning as a programming language, and see nothing to be gained by crippling its ability to function in that role.  As noted there is a move now towards the creation of executable papers to allow journale articles to be better reviewed.  Opening the dREL features to more general use than just in dictionaries would allow the IUCr to explore this very important direction and be more competitive with Elsevier, so I strongly disagree with John's value judgement that a rich feature set is somehow negative.

Evidently I am not catching your vision.  Can you be a bit more concrete about how you imagine such an executable CIF might be structured and might operate?  Do you assert that it could work within the CIF2 framework, +- tweaks?

As for dREL features, is it not the case that dREL and ddlm are to be implemented in CIF2, and indeed that some of the new CIF features are expressly driven by the need to support that?  If you have discovered CIF2, as previously formulated by this group, to be insufficient for that purpose then I am certain that we would all be very interested in your findings.  I don't see how any formulation of CIF2 that adequately supports dREL itself could be insufficient to support more general use of dREL features.

>2.  I find the ability to have escapes to handle the "illegal" characters useful for imgCIF which need to be able to handle at least the range of 15 out of 16 bits without breaks.

This is not a matter of disagreement.  I have proposed adopting Python's \uxxxx and \Uxxxxxxxx elides, which cover all of the nearly 21-bit Unicode code space.

There is an additional question here, however, which I had planned to raise in its own message: if CIF2 provides general elides such as those, then should it accept ones representing characters that are not in the CIF character set (ASCII control characters, for example)?  I see no particular reason why not, but this is an area of possible confusion, so let's be explicit.

>3. I find the \N{}, \a, ... constructs useful for the reasons in 1, above.  In point fo fact, I think we would be best of following Brian's original approach of being "maximally disrupttive" and requiring a uniform translation of all the IUCr glyphs that conflict with current programming practice to an escaped form \\a

Even if I were to subscribe to the concept that CIF should aim to morph into a programming language, I still would object to \N{}, to hexadecimal and octal escapes, and to at least some of the single-character elides.  Furthermore, if programmable CIF is to be a target, then it is not at all clear that a Python-like form would be best for that.  I can see potential advantages for Ruby-based and even bash-based forms, and likely there are other reasonable targets.

>In any case, I think you should get the point -- this really is a matter of taste, not a technical issue.
>I find python compatability a strong plus to help move us into the executable paper realm, indeed to help move CIF into being a scripting language.

I think you shortchange us both by characterizing this merely as a matter of differing taste.  It is clear to me that much of our disagreement stems from differing design priorities.  Taking ddlm / dREL support as a given, I am looking most for ease of transition from CIF1 (software, files, and minds), ease of correct implementation, and continued strong support of CIF's current areas of application.  Although I am sure you value those objectives as well, your recent arguments have focused on CIF's overall development direction and its suitability for future applications.  Our priorities are not necessarily incompatible, which is largely why I am pressing you to be more concrete about what you have in mind.

However, to the extent that I have accurately identified your focus, I think it is a matter for COMCIFS to address.  If COMCIFS has no current corporate intention to move toward or prepare for a transition to CIF as a scripting language, then it is inappropriate for this group to prioritize features in support of such a move.  On the other hand, my own priorities are based on my interpretation of the charter for this working group, and if I have misjudged that then I may need to revisit some of my own positions.  Is it really true that after all this time, CIF2's design objectives are not agreed?

In any case, I don't personally see any advantage to making CIF into a scripting language; there are already more than enough of those.  If anything, I could see embedding script in CIF, ala HTML/Javascript.  If that were a direction of interest, then I see similarity of CIF's quote syntax with the chosen scripting language's syntax to be at best neutral, but possibly negative: if you embed script as CIF data values, then similarity of CIF and script string literal syntax may lead to a greater need for elision of the script text.  Alternatively, if the script is somehow hidden from the CIF layer, then what advantage does similar syntax provide?

On the other hand, if one posits a Python module that provides for expression of CIF data in executable Python form, then I see no reason to suppose that it would require data values to be expressed according to CIF syntax rules.

Do you imagine another alternative?


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
ddlm-group@iucr.org
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