Discussion List Archives

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

Re: Important CIF items for discussion

My thoughts on the three issues raised by David.

1. Virtual dictionaries

I favour option D (the dictionary is contained within the datablock as
the text value of a dataitem).  This ensures that the dictionary
remains as close as possible to the dataitems it is concerned with.
Note that creating a CIF with such a built-in definition in no way
forces the IUCr to condone the content of that definition: if someone
were to define betas in their CIF and then submit a CIF with betas
rather than UIJs, the IUCr remains free to act as it has in the past
(especially if the beta definition boils down to a description along
the lines of "beta i j as conventionally defined").

The technical issues boil down to being able to escape the
"<EOL><semicolon>" digraphs in the embedded dictionary text, which
would otherwise prematurely end the datavalue.  Some suggestions:

(1) Define "<backslash><semicolon>" as being an escaped semicolon (and
this would require defining "<backslash><backslash>" as an escaped
backslash in order to cope with those situations in which you actually
want the text that comes out to be "<backslash><semicolon>").
Obviously the escaping character doesn't have to be backslash.

(1a) Define "<EOL><backslash><semicolon>" to be an escaped "<EOL><semicolon>".

(2) Substitute <EOL><hash> for <EOL> in the entire text field.  This
immediately signals to the human reader that the entire text field is
a single block, rather than bits of a CIF file (same as quoting in
emails), and is easily reversible.  And nestable, but let's not go
there...

I would note in passing that Option B (the IUCr accepts and
administers deposited dictionaries) is appealing in that the IUCr
could take care of checking dictionary correctness and keeping track
of what was defined by whom and when.  But if DDLm were actually to
expand beyond the confines of the IUCr this would not be a useful
option, as other fields may not have a well-developed central
organisation and at the same time would be in even greater need of a
method of passing around dataitem definitions.

2. Hierarchy of methods

I would cautiously advocate allowing a looped list of methods with a
priority indicator.  Dictionary validation tools should attempt to
test both methods and make sure that the resulting values are
identical to within some precision.  In general I wouldn't expect this
situation to crop up all that often.

3. Intermediate values

I go with option A, to prohibit the definition of intermediate values.
 An item defined in an official CIF has an important status and we
shouldn't water that down or introduce unnecessary complexity.  I
believe that the correct way to deal with the intermediate result
issue is to add a new function to the function category (e.g.
BetaFromUIJ).  *Implementations* of dREL are then free to attempt
caching of results (eg by defining for themselves an internal dataitem
attached to that function) for efficiency and the dictionary retains
its purity.

Best wishes,
James Hester.

On Sat, Jul 12, 2008 at 1:33 AM, David Brown <idbrown@mcmaster.ca> wrote:
> I have attached to this email a dicsussion paper concerning three issues
> that have arisen during our evaluation of the new DDLm.  These are important
> issues for the future of CIF, and before I ask the voting members of COMCIFS
> to make a decision, I would like to see the issues fully discussed and, if
> possible, a consensus reached.  The attached document is six pages long, but
> I hope you will take the time to read it and comment on the issues raised.
>
> I apologize if you have received this message more than once by being on
> more than one discussion list.  Please ignore the second email.
>
> David Brown
> Chair, COMCIFS
>
> _______________________________________________
> comcifs mailing list
> comcifs@iucr.org
> http://scripts.iucr.org/mailman/listinfo/comcifs
>
>



-- 
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

Reply to: [list | sender only]