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

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

You assumed correctly.  Herbert has not yet stated what these
revisions entail, but the only revisions I can determine are simple
technical ones, relating to our changed syntax for tables and removal
of tuples.  I see no cause for concern.

On Sat, Jan 15, 2011 at 8:11 AM, SIMON WESTRIP
<simonwestrip@btinternet.com> wrote:
>>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.
>
> I assumed that DDLm/dREL would be finalized in accord with CIF2 and
> vice-versa?
> Surely a DDLm dictionary will share the same syntax and data types as a CIF
> file?
>
>
>
> ________________________________
> From: Herbert J. Bernstein <yaya@bernstein-plus-sons.com>
> To: Group finalising DDLm and associated dictionaries <ddlm-group@iucr.org>
> Sent: Friday, 14 January, 2011 20:29:34
> Subject: Re: [ddlm-group] Relationship asmong CIF2, STAR, CIF1 and Python. .
> . .
>
> 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]