Request for a vote on a motion

Herbert J. Bernstein yaya at bernstein-plus-sons.com
Mon Sep 20 15:35:59 BST 2010


Dear Colleagues,

   While I would prefer a formal COMCIFS vote to provide an interim
solution for this issue that is holding up all progress on CIF2, if
James would like to have a vote of the subcommittee first,
then let us do that, but please, let us do it immediately, and, if
it passes, relegate further consideration of changing CIF from a text
format to a non-text format to some future variant of CIF and put
an end to it blocking progress on the transition to CIF2.

   CIF has served the community well as a text format for many years.
It ain't broke, so fixing it is not the issue.  Except for the
transition from ASCII to Unicode as the reference exemplar for
text, the rest of what is being discussed can wait until a
clear consensus on making such improvements emerges.

   It this rate we will have nothing ready to present at Madrid other
than the record of a debate, an interesting debate, but a debate on
a side issue none the less, not on the critical issues in helping the
community to make the transition to CIF2, most of which are not being
discussed, much less resolved.

   I personally disagree with James' assessment that "the DDLm encodings
group is close to resolving the encoding issue," and believe that
it is time to vote and move on so we will have a sound CIF2 proposal
with supporting software to present to the community.  Except for
making the change from ASCII to Unicode and UTF8, on which there
does seem to be broad consensus, I believe all the rest of the
encoding debate can and should wait for resolution until after CIF2
is adopted and until the Chester office has had time to gain experience
with CIF2 in the journal flows.  Most of what has been proposed
comes down to externally mandating how the journal flows should be
handled, rather than having a standard that reflects the practical
realities that I am certain the Chester office will handle well
without the need for us to do their thinking for them.

   If the subcommittee does not act promptly, I hope some other voting
member of COMCIFS will second my motion so we can resolve this
issue for the interim and move on with CIF2 itself.

   Regards,
     Herbert




At 11:54 PM +1000 9/20/10, James Hester wrote:
>Dear COMCIFS members and observers:
>
>As the matters presented in Herbert's motion are currently being
>actively considered by a COMCIFS subcommittee created specifically for
>discussing and assessing these issues (the DDLm working group), I
>would like to move that Herbert's proposal be referred to that
>subcommittee.
>
>For those who came in late:
>Around August last year a DDLm working group was formed to finalise a
>set of specifications for presentation to COMCIFS for approval.  As
>Herbert notes, this working group released a draft syntax standard in
>June this year, which has been available since then for comment.  Due
>to objections to the encoding method put forward in that draft, a
>subgroup (including Herbert) was formed to explore and resolve the
>issues around text encodings.  That subgroup is currently considering
>a number of proposals; a record of the ongoing discussions can be
>found at http://www.iucr.org/__data/iucr/lists/cif2-encoding.
>
>I appreciate that the DDLm standard is taking frustratingly long to
>finalise.  My perception is that the DDLm encodings group is close to
>resolving the encoding issue, whether by consensus or vote, at which
>point a final draft will be presented to COMCIFS with enough
>supporting material to allow COMCIFS to make an informed decision.
>
>James.
>
>On Sat, Sep 18, 2010 at 11:39 AM, Herbert J. Bernstein
><yaya at bernstein-plus-sons.com> wrote:
>>  Point well taken.  To ensure that the voting members of COMCIFS see
>>  this message in their role as voting members of COMCIFS, I am copying
>  > it to that  list as well.
>>
>>  Dear Colleagues on COMCIFS.  There has been a long and interesting
>>  discussion of various alternatives for handling or not handling
>>  various encodings of text for CIF2 and/or recasting CIF as a UTF-8 based
>>  binary format.  These discussions have not achieved anything approximating
>>  agreement on these issues, but we do seem to have agreement on the
>>  important of extending CIF to handle Unicode, and on the desirability
>>  of UTF8 serving the role that ASCII has long held as a preferred
>>  default encoding for CIF.  In my opinion, it is a mistake to hold
>>  release of CIF2 hostage to what is, frankly, a minor side-issue.
>>  CIF has long-established practices with respect to the role of
>>  ASCII and text in CIF that have been formally adopted by COMCIFS
>>  in the form of the current CIF 1.1 syntax specification.  The
>>  appended proposed resolution combines the currently adopted CIF
>>  practice with respect to ASCII and text with the minimal changes
>>  necessary to follow those same practices with respect to Unicode
>  > and UTF8 accepting what has been proposed to the community as
>>  a whole as the changes that will make CIF2.  In the 2+ months
>>  since that proposal, nobody has objected to anything in that
>>  document other than to the way in which UTF8 was proposed.  The
>>  motion below simply combines was has not caused objection with
>>  the practices previously adopted by COMCIFS and defacto in use for
>>  many years.  Until we have agreement on something else -- which
>>  seems likely to take years more of debate -- I urge all concerned
>>  to accept this imperfect motion as the best we can do for now
>>  so CIF2 can be used.
>>
>>  Please consult sections 22 and 23 of the CIF 1.1 syntax specification
>>  and the "CIF Changes to the specification 05 July 2010", and then
>>  please consider the appended motion submitted for formal vote by
>>  COMCIFS.  If anybody likes the basic idea of a minimally disruptive
>>  change to what has already been agreed for CIF2, but wants
>>  some minimal wording changes, the right way to do that is just to
>>  proposed the specific wording changes you propose as an amendment
>>  to this motion to be voted on first, but please, let us get something
>>  agreed to promptly.  Elephants get born is less time than CIF2 is
>>  taking.
>>
>>  ===============================================================
>>
>>  Proposed position on CIF2 character encodings submitted to
>>  COMCIFS for a vote as an interim agreement on what can be
>>  agreed thus far, subject to extension and refinement in
>>  the future.
>>
>>  ===============================================================
>>
>>  Reference to character(s) means abstract characters assigned code
>>  points by Unicode.  Specific characters are referenced according to
>>  Unicode convention, U+xxxx[x[x]], where  xxxx[x[x]] is the four- to
>>  six-digit hexadecimal representation of the assigned code point.
>>
>>  The designated character encoding for CIF2 is UTF-8 as the preferred
>>  concrete representation of the information in a CIF2 document.
>>
>>  Reference to ASCII characters means characters U+0000 through U+007F, or,
>>  equivalently the first 128 characters of the ISO-8859-1 (LATIN-1)
>>  character set.
>>
>>  Reference to newline or \n means the sequence that conventionally
>>  terminates a line record (which is environment dependent).
>>  Reference to whitespace means the characters ASCII space (U+0020),
>>  ASCII horizontal tab (U+0009) and the newline characters. Without
>>  regard to local  convention, the various other characters that
>>  Unicode classifies as whitespace (character categories Zs and Zp) do
>>  not constitute whitespace for the purposes of CIF2.
>>
>>  CIF2 files are standard variable length text files, which for
>>  compatibility with older processing systems will have a maximum line
>>  length of 2048 characters. As discussed above and below, however,
>>  there are some restrictions on the  character set for token
>>  delimiters, separators and data names.
>>
>>  References to Unicode and UTF-8 are specifically to identify characters
>>  and a concrete representation of those characters in an established and
>  > widely available standard.  It is understood that CIF2 documents may
>>  be constructed and maintained on computer that implements other character
>>  encodings.  However, for maximum portability only the clearly
>>  identified equivalents to the Unicode characters identified above and
>>  below should
>>  be used and use of UTF-8 for a concrete representation is highly
>>  recommended.
>>
>>  A CIF2 file is uniquely identified by a required magic code at the
>>  beginning of its first line. The code is, #\#CIF_2.0 followed
>>  immediately by whitespace.  The addition of further information
>>  to assist in disambiguation among multiple characters sets is
>>  under discussion.  Encodings, such a UTF-16, which prefix a file
>>  by a BOM (byte-order-message) or other encoding disambiguation
>>  prefix are not precluded.  In such a case, the magic code should
>>  follow the encoding disambiguation prefix.
>>
>>  In keeping with XML restrictions we allow the characters
>>
>>  U+0009 U+000A U+000D
>>  U+0020 -- U+007E
>>  U+00A0 -- U+D7FF
>>  U+E000 -- U+FDCF
>>  U+FDF0 -- U+FFFD
>  > U+10000 -- U+10FFFD
>>
>>  In addition, character U+FEFF and characters U+xFFFE or U+xFFFF where
>>  x is any hexadecimal digit are disallowed. Unicode reserves the code
>>  points E000 - F8FF for private use. The IUCr and only the IUCr may specify
>>  what characters  are assigned to these code points in the context of
>>  CIF2.
>>
>>  CIF2 processors are required to treat <U+000A>, <U+000D> and
>>  <U+000D><U+000A> as newline characters, by normalising them to
>>  <U+000A> on read. No other  characters or character sequences may
>>  represent newline. In particular, CIF2  processors should not
>>  interpret the Unicode characters U+2028 (line separator) or U+2029
>>  (paragraph separator) as newline.
>>
>>
>>
>>
>>  At 5:42 PM -0500 9/17/10, Bollinger, John C wrote:
>>>On Friday, September 17, 2010 5:06 PM, Herbert J. Bernstein wrote:
>>>>I am formally asking for a vote of all COMCIFS voting members on 
>>>>the proposed
>>>>wording as it stands.
>>>
>>>It is your privilege to do so, but if you genuinely want a formal
>>>COMCIFS vote -- as opposed to a vote of the participants in this
>>>discussion -- then I do not believe the motion is in order in this
>>>forum.
>>>
>>>If you would be satisfied with a vote of the discussion
>>>participants, then I vote NO.
>>>
>>>
>>>Regards,
>>>
>>>John
>>>--
>>>John C. Bollinger, Ph.D.
>>>Department of Structural Biology
>>>St. Jude Children's Research Hospital
>>>
>>>
>>>Email Disclaimer:  www.stjude.org/emaildisclaimer
>>>
>>>_______________________________________________
>>>cif2-encoding mailing list
>>>cif2-encoding at iucr.org
>>>http://scripts.iucr.org/mailman/listinfo/cif2-encoding
>>
>>
>>  --
>>  =====================================================
>>   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 at dowling.edu
>>  =====================================================
>>  _______________________________________________
>>  comcifs mailing list
>>  comcifs at iucr.org
>>  http://scripts.iucr.org/mailman/listinfo/comcifs
>>
>
>
>
>--
>T +61 (02) 9717 9907
>F +61 (02) 9717 3145
>M +61 (04) 0249 4148
>_______________________________________________
>comcifs mailing list
>comcifs at iucr.org
>http://scripts.iucr.org/mailman/listinfo/comcifs


-- 
=====================================================
  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 at dowling.edu
=====================================================


More information about the comcifs mailing list