Discussion List Archives

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

Re: [ddlm-group] Latest draft specification

As I am not a subscriber to any of these lists, perhaps somebody who is a subscriber could handle posting an announcement and relaying back to this group the salient points in any ensuing discussion?  I've included below a slightly edited text of the original annoucement to the cif-developers list as a possible announcement text.

James
==========================
Dear CIF users,

As some of you may be aware, a new CIF dictionary framework is under
development. This framework consists of an updated CIF syntax
(CIF2), a new set of dictionary attributes (DDLm), and a

machine-readable language for describing algorithmic relationships
between datanames (dREL).  The working group for developing this new
framework has come up with a final draft for the CIF2 syntax
component, which is available at


http://www.iucr.org/__data/assets/pdf_file/0017/41426/cif2_syntax_changes_jrh20100705.pdf

We are now seeking feedback from the community on this proposed new

syntax standard.  Please note that this CIF2 standard is designed to
coexist with the CIF1 standard (which it closely resembles), rather
than to replace it.

The discussions surrounding the CIF2 specification are archived at

http://www.iucr.org/__data/iucr/lists/ddlm-group/ .

Some highlights of the the proposed CIF2 syntax:

* A list datavalue is introduced: lists are enclosed by square

brackets, e.g. [1 2 3 4] or  [[1 'x'] 3 ['y' 5 ['pqr' 7] 8 ]].
List-valued data items are vital for economically expressing matrix
and vector relationships in dREL algorithms.

* A table datavalue is introduced, enclosed by curly braces, e.g.

{"colour":"red" "size":"really big"}.  Table datastructures allow
tabulated values (e.g. f' values) to be transparently accessed in dREL
algorithms.

* Both lists and tables are recursive, that is, lists and tables can

contain other lists and tables

* Multi-line strings may now be delimited using triple quotes (""") or
triple single quotes ('''), as well as the CIF1.1 <newline><semicolon>

delimiter.

* Single-quote delimited strings and double-quote delimited strings
may not contain instances of the delimiter character.  This differs
from the CIF1.1 standard, which allowed instances of the delimiting

character if the next character was not whitespace.

* CIF2 files are in UTF8 encoding.  Note that ASCII is a proper subset of UTF8.

The DDLm working group would welcome any feedback you may have on this
specification, whether through open discussion on this list or by

contacting members of the working group (see the online discussion
archive for names of the participants).

On Mon, Jul 5, 2010 at 11:54 PM, Herbert J. Bernstein <yaya@bernstein-plus-sons.com> wrote:
Even though I do not agree with many of the restrictions in this document, I urge starting discussion of these changes on the various community-wide
discussion lists.  I suggest announcements to pdb-l, ccp4bb and ccp4-dev
lists.

   -- 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 Mon, 5 Jul 2010, James Hester wrote:

Brian has now posted the document.  You can find it at:
http://www.iucr.org/resources/cif/spec/cif-2-development


On Mon, Jul 5, 2010 at 2:19 PM, James Hester <jamesrhester@gmail.com> wrote:
     I am happy to proceed as Brian suggests.  As far actually preparing a draft goes, on May 7 John B kindly
     provided me with an editable version of the original draft specification with those suggested changes of
     his that were uncontroversial already included.  I have updated that draft making the following specific
     changes:

     1. Change the 2048-byte limit to a 2048-character limit
     2. Incorporate XML-type newline handling
     3. Refer to UTF-8 as the designated encoding for files conformant to the specification
     4. State that U+FEFF is not part of the allowed character set (ie. would be everywhere a syntax error).  I
     include this as the voting on this point, such as it was, gave a slight majority to option 2(a) over option
     2(c)(ii).
     5. Disallow Unicode non-characters.  I have *not* dealt with the issue of disallowing non-printing
     characters.  As the draft currently stands, non-printing characters are acceptable. 

     The updated draft is in Brian's hands, and I'm hoping he will post it to the IUCr website shortly for your
     comment.

     James.

     On Fri, Jul 2, 2010 at 6:25 PM, Brian McMahon <bm@iucr.org> wrote:
           Colleagues

           Like Buridan's ass we are starving to death between the equally
           enticing mound of hay that is UTF-8 and the smorgasbord of mixed
           vegetables offered by multiple encodings.

           I suggest that this group complete a *draft* CIF2 specification
           that describes (if necessary) specific character allusions in
           terms of a canonical UTF-8 encoding, and states that UTF-8 is the
           designated encoding for files conformant to the specification.

           Post the completed draft in the first instance to the cif-developers
           list (since that is supposed to the the most relevant target audience),
           but certainly to other lists at the same time if folk think that would
           be productive. By all means accompany the release with a commentary on
           the difficulties we have faced over the encoding issue; by all means
           implement a survey and analyse the results to assess community demand
           for an upward revision of the draft - but let us give people something
           concrete to begin with, and challenge them actively to protest if the
           proposal will impede their work.

           Note that this proposal doesn't necessarily reflect a personal
           preference for a single mandatory encoding - I still cannot
           decide which I "prefer". But if the suggested draft is published,
           I will not vote against it unless I suddenly see clearly a real
           problem that it would throw up in the way of any applications I
           would envisage writing. I would hope "the community" would respond
           in similar vein, so that stated objections would both represent real
           difficulties and help to define the environments giving rise to these
           real difficulties.

           Best wishes
           Brian
           _______________________________________________
           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




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




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