[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 <ddlm-group@iucr.org>
- Subject: [ddlm-group] CIF 1.5
- From: James Hester <jamesrhester@gmail.com>
- 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 <yaya@bernstein-plus-sons.com> 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
yaya@dowling.edu
=====================================================
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 <yaya@bernstein-plus-sons.com>
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
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]
- 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):