[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
(For those who came in late:
We flirted with the idea of a minimally disruptive path from CIF1.1 to CIF2.0 back in the beginning of this group (late September/early October, I believe) , and ended up choosing to define one maximally disruptive CIF2.0 standard together with a commitment to support CIF1.1 for the long term and a guaranteed way to distinguish the two types of data files.)
Picking up the CIF1.5 discussion...
Introducing CIF1.5 is a further source of confusion.� Apart from this, it produces extra workload for software authors.� Herb has essentially defined CIF1.5 as CIF1.1 plus new syntactical elements (or in other words CIF2.0 minus character set limitations and UTF8).� So in order to support CIF1.5, authors of both CIF reading and CIF writing software have to add this new syntax.� Then when they decide to support CIF2.0, they have to once again revisit their software.� I would have thought it far more sensible to ask them to update and distribute their software only once.� Furthermore, they now have to support one more type of file going into the future.
I see absolutely no benefit in this idea.�
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
Reply to: [list | sender only]
[ddlm-group] CIF 1.5
- To: Group finalising DDLm and associated dictionaries <[email protected]>
- Subject: [ddlm-group] CIF 1.5
- From: James Hester <[email protected]>
- Date: Tue, 1 Dec 2009 10:35:04 +1100
(For those who came in late:
We flirted with the idea of a minimally disruptive path from CIF1.1 to CIF2.0 back in the beginning of this group (late September/early October, I believe) , and ended up choosing to define one maximally disruptive CIF2.0 standard together with a commitment to support CIF1.1 for the long term and a guaranteed way to distinguish the two types of data files.)
Picking up the CIF1.5 discussion...
Introducing CIF1.5 is a further source of confusion.� Apart from this, it produces extra workload for software authors.� Herb has essentially defined CIF1.5 as CIF1.1 plus new syntactical elements (or in other words CIF2.0 minus character set limitations and UTF8).� So in order to support CIF1.5, authors of both CIF reading and CIF writing software have to add this new syntax.� Then when they decide to support CIF2.0, they have to once again revisit their software.� I would have thought it far more sensible to ask them to update and distribute their software only once.� Furthermore, they now have to support one more type of file going into the future.
I see absolutely no benefit in this idea.�
On Tue, Dec 1, 2009 at 9:40 AM, Herbert J. Bernstein <[email protected]> wrote:
Dear James,
�The point is that we will need to make it easy for people working with
CIF 1 and CIF 1.1 based tools to cobble together valid CIF 2 data. �The
most important bit will be a way to include vectors and matrices in their
data. �This will allow them to do it.
�Please note that it hase taken several years to just get to the point
where we are beginning to rigorously define CIF 2. �If we are lucky, it
will only take a few years to have a full set of tools to allow users
and software writers to reliably produce true CIF 2 data.
�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
� � � � � � � � [email protected]
=====================================================
On Tue, 1 Dec 2009, James Hester wrote:
Dear Herbert: as CIF 1.1 doesn't define lists, I'm not sure why you suggest that the
example below is a valid tag.
On Tue, Dec 1, 2009 at 12:36 AM, Herbert J. Bernstein <[email protected]>
wrote:
� � �Sorry something got lost in the prior message. �It should have
� � �read:
� � � � � �Dear Colleagues,
� � � � � ��Back to the question of commas. �If you accept the desirability
� � � � � �of
� � � � � �having a CIF 1.5, commas in lists become very useful. �Someone
� � � � � �with
� � � � � �a CIF 1.1 editor will be able to prepare a CIF 1.5 file for many
� � � � � �useful cases by doing all lists with commas and no embedded blanks
� � � � � �as long as they can make their lists fit on single lines. �In CIF
� � � � � �1.1
� � � � � �[[1,2,3],[4,5,6],[7,8,9]]
� � � � � �is a valid value for a tag, but
� � � � � �[[1 2 3] [4 5 6] [7 8 9]]
is not.
No, neither example is a valid CIF 1.1 tag.� CIF 1.1 explicitly excludes brackets as the
first character of a non-delimited string.
� � � � � �Having the option of commas in lists will help to smooth the
� � � � � �transition for at least some people.
--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
[email protected]
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 [email protected] http://scripts.iucr.org/mailman/listinfo/ddlm-group
Reply to: [list | sender only]
- Follow-Ups:
- Re: [ddlm-group] CIF 1.5 (Herbert J. Bernstein)
- Prev by Date: Re: [ddlm-group] Stakeholders
- Next by Date: [ddlm-group] Role of separators in CIF
- Prev by thread: Re: [ddlm-group] Syntax summary? Wiki?
- Next by thread: Re: [ddlm-group] CIF 1.5
- Index(es):