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. . . .

See my comments below.

On Sat, Jan 15, 2011 at 2:50 PM, Herbert J. Bernstein
<yaya@bernstein-plus-sons.com> wrote:
> Dear Simon,
>
>   Please read both the DDLm and dREL documents,
> and then reread John Bolliger's comments on
> trying to force CIF2 not to be a programming
> languages.  I don't see how we are going to
> properly support DDLm in a CIF2 context with
> such an approach.  We _need_ CIF2 to be a
> programming language if it is to support dREL
> to form DDLm dictionaries, because those dictionaries
> are programs.

This paragraph makes no sense whatsoever.  Both my own
proof-of-concept code and Nick and Syd's code show that dREL works
fine with DDLm and CIF2 syntax. Herbert is therefore talking about a
problem that doesn't exist.  I advise everybody to examine the
specification documents to assure themselves of this.  If you,
Herbert, disagree, give a concrete example of the problem, and not
ex-cathedra assertions.

>   Sure, were can make some changes to DDLm snd
> dREL, but we really should not try to drag
> them into a programming-language-hostile environment.
> On the contrary, we should be sure to provide
> rich programming language support, which means
> getting more pythonesque, not less.

There is nothing hostile about CIF2 to programs.  Quite the reverse,
it is a reasonably elegant serialisation of a relational database, and
as such provides the datastructure for dREL algorithms to operate on.
If you think otherwise, please give a concrete example of how the
current CIF2 syntax is "hostile" to dREL and DDLm, ideally with a
particular dREL method calculating a particular value for a particular
dataname.

>   dREL is already 90% compatible with Python.
> I would suggest we consider go all the way and simply
> make the dREL methods into Python scripts or scripts
> in some other well-supported programming language,
> make all string literals follow the string conventions
> conventions of that language, adapt CIF2 to that
> language.  Maybe dREL is already that scripting
> language, but in any case we are dealing with
> programming language issues, and cannot avoid them.

I do not see the problems you see.  You will need to give concrete
examples for me to grapple with.  dREL is specifically designed for
the abstract CIF datastructure (relational database).  I would oppose
any tinkering with it without a clear demonstration - using concrete
datanames and algorithms (not vague assertions)- of exactly why it is
not suited for purpose.

>   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 Fri, 14 Jan 2011, Herbert J. Bernstein wrote:
>
>> Dear Colleagues,
>>
>>   I would suggest recalling that this CIF2 exercise began with
>> tryin to define a DDLm/dREL-friendly version of CIF.  To the best
>> of my knowledge, the current DDLm spec is at what is published
>> on the IUCr web site under http://www.iucr.org/resources/cif/ddl/ddlm
>> with draft documents from August 2008.  I propose that we all
>> take the time to review those documents and make a conscious
>> effort to decide if we wish to make use of them as a
>> base for CIF2 or not.  They contain many points relevant
>> to the current discussion.  For example:
>>
>> 1.   the top level page contains the bold-faced assurance to
>> the community that "No changes are required in existing archival
>> data files in order to apply domain dictionaries written in DDLm".
>> Do we wish to return to that "minimally distruptive" approach, or
>> do we wish to continue on the current "maximally disruptive
>> approach" and why.
>>
>> 2.  The DDLm document describes Lists and Arrays as being bracketed
>> by [], Tuples as being bracketed by (), and Tables as being
>> bracketed by {}.  Do we wish to return to that spec, or to
>> use the revised spec which avoids [], and why?
>>
>> 3.  The dREL document describes rather pythonesque string literals
>> with cooked, raw and Unicode strings, treble quotes, C-style elides and
>> much more that has been rejected by this group.  Do we wish to
>> bring the full dREL data type collection into CIF2 or not, and
>> why.  If we reject some portion of the dREL data types, what
>> shall we do when a dictionary method using those type generated
>> a data item of a type we have rejected?
>>
>> I had been under the mistaken impression that much of what this
>> group decided had been donwe to achieve compatability with
>> the new STAR and with DDLm and dREL.  It is now clear, that
>> instead of achieving compatibility we have made integration
>> of CIF2 with CIF1, STAR, DDLm and dREL more difficult.
>>
>> The more I look over the original DDLm and and dREL documents,
>> the more convinced I am that we either need to revise CIF2 to
>> conform with them, or we need to revise them to conform with
>> CIF2 or both.
>>
>> It is time to start over.
>>
>> 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 Fri, 14 Jan 2011, Bollinger, John C wrote:
>>
>>> On Friday, January 14, 2011 9:23 AM, Herbert J. Bernstein wrote:
>>>> hearing what others think on the current version of CIF2 feature by feature would help.
>>>
>>> I structure these comments after the changes document, and I comment primarily about the changes and additions in CIF2.  If more is desired then I probably need a list of the CIF features about which comments are solicited.
>>>
>>> * Feature: Magic Code
>>> This, or something like it, is necessary to enable CIF parsers to adapt automatically to CIF1 vs. CIF2 input.  I consider that a worthwhile thing to be able to do, so I am in favor of this feature.
>>>
>>> * Feature: Unicode support This is my favorite new CIF feature, though I
>>> think it could be slightly improved: 1) I think certain Unicode
>>> character categories (space and control characters) should be forbidden
>>> in data names 2) I think data block and save frame codes should follow
>>> the same rules as data names (except for the leading underscore),
>>> subject to line length limitations (it's not altogether clear from the
>>> changes document whether they do, but I have supposed not)
>>>
>>> I do not object to limiting recognized whitespace characters and
>>> newlines as CIF2 currently does.  However, if (1) above were adopted
>>> then it would provide a clearer path to possible future full adoption of
>>> Unicode whitespace semantics.
>>>
>>> I remain satisfied with the compromise we reached on encoding.
>>>
>>> * Change: treatment of newline I am on record as favoring this sort of
>>> treatment as far back as during the preparation of CIF 1.1, and I still
>>> favor it.
>>>
>>> * Change: allowed whitespace-delimited data values I would be happier if
>>> it were not necessary to place stronger restrictions on the ASCII
>>> content of these values, but if list and table data types are retained
>>> then I can live with it. For forward-looking compatibility, it might be
>>> better to forbid Unicode whitespace from appearing in these, even though
>>> allowing such characters is not a problem for CIF2.
>>>
>>> * Change: string delimiters ('") cannot be embedded in data values they
>>> delimit As unusual as CIF1's rules for quoted data values are, I do not
>>> favor changing them in CIF2.  I would find the change more palatable
>>> with the addition of some sort of escape or elide by which the delimiter
>>> could be embedded, but more than that I would favor backwards
>>> compatibility.
>>>
>>> * Restriction: text blocks cannot contain <newline>; This is not a
>>> change from CIF 1.1 as far as I can tell, but our discussions have shown
>>> that it differs at least from some older interpretations of CIF.  I am
>>> satisfied with it, and I prefer it for compatibility with CIF 1.1.  If
>>> there were evidence of a non-trivial body of CIFs relying on a different
>>> interpretation, and if the changes to single-quoted string formatting
>>> were reversed, then I might be persuaded to change my mind.
>>>
>>> * Feature: triple-quoted strings I have never been especially hot about
>>> these, but I saw the advantage they provided when coupled with the
>>> changes to single-quoted string syntax, and their use for quoting text
>>> block delimiters.  I also see a compatibility advantage to using
>>> exclusively these for new syntax and semantics, such as we have recently
>>> been discussing.  I am mildly supportive.
>>>
>>> * Feature: list data type Inasmuch as this is supposedly needed for ddlm
>>> / dREL, I'm OK with it.  I imagine there are other reasonable use cases
>>> as well, though none presently come to mind.  I don't object to it, but
>>> neither do I particularly favor it.
>>>
>>> * Feature: table data type My opinion of this is pretty much the same as
>>> of the list data type.  I am slightly more negative about it because it
>>> requires a restriction of allowable whitespace-delimited data values
>>> relative to CIF 1.1, but I still do not object.
>>>
>>> * Undocumented Change: updated data model I have lately realized that
>>> many of the CIF2 syntax changes imply changes to the CIF data model, but
>>> that I find no documentation of those data model changes.  Really, the
>>> data model updates should have been settled first, for the syntax serves
>>> the model, not the other way around.  This would answer questions such
>>> as the one I recently injected into the elide discussion, about whether
>>> elides should be accepted that represent characters outside the revised
>>> CIF character set.
>>>
>>> I have no problem with extension of the CIF1 data model, but I think we
>>> need to better characterize the details of the new model.
>>>
>>>
>>> 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
>>>
>> _______________________________________________
>> 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


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

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

ICSU 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.