Re: _atom_site_aniso_label is broken

[Nick Spadaccini <nick@xxxxxxxxxxxxx>]

On Tue, 21 Jun 2005, James Hester wrote:

> I read this as meaning that the quick fix has broken the explicit
> semantics, and we must now fall back on the intention (as given in the
> _atom_site_aniso_label description) to guide us in making valid/not
> valid decisions.  I'm afraid I don't understand why implied semantics
> can't be made explicit.

You had to be there when all this was going on. Since then it goes to my 
comment in a previous message on this thread about what developers did (1) 
ent to another DDL, (2) waited for someone else to solve the problem and 
(3) went away to create a you-beaut all encompassing DDL and forgot to 
come back.

Much of DDl1.4 resulted from a flurry of ideas in a time when there was a 
vacuum of knowledge in these approaches. The semantics weren't made 
explicit and people haven't bothered to return to the problem - rather 
developing systems based on their interpretation. Is this correct or even 
adequate - hell no but it is the way it is.

>>> document describing DDL1.4 completely silent on these implicit joins?  I
>>> attach some relevant paragraphs from the DDL1.4 spec
>>> ftp://ftp.iucr.ac.uk/pub/ddldic.c95 - where would we expect to see an
>>> explanation of this behaviour?

I rectified (clarified) the idea of JOINs in my last message replying to 
John. I am correct in stating that _atom_site and _atom_site_aniso lists 
could (and do) appear in one list. It is not true that all lists related 
by link_list_parent/_child relationships can (or should) be joined. A 
_geom_bond list would be a case in point.

> So there are two alternative interpretations [must occur in loop; must
> occur in loop with unique value], which is not the same as no behaviour.

I don't think I said that. If it occurs in a loop it must have a unique 
value (in the column row). Specifically for _atom_site and 
_atom_site_aniso lists they can appear in separate lists each with a 
unique identfier or in the same list with only one of the labels necessary 
to uniquely identify the records. What I am describing here is (was) 
accepted behaviour you won't find stated in any DDL definition.

> I maintain that it is possible to come up with a consistent
> interpretation for all of the DDL1 definitions which can be programmed
> into a validity checking program, and while this interpretation might
> not be a unique interpretation, it is consistent with the standard.

I think this particular case is made difficult because 
link_list_parent/_child can't be uniquely used to decide whether two lists 
can be JOINed or not.

> I'm not a standards-type guy, but the idea of implicit behaviour being
> part of a standard doesn't sound right, especially if a single paragraph
> could be added to the DDL1.4 spec for _list_link_child to make things
> explicit - and if it is so unimportant then why doesn't someone just add
> in this paragraph and we can all go home?

As above, you can't define it in _list_link_child because that isn't the 
tag that uniquely identifies whether you JOIN or not. Again that is the 
tag to point to _geom_bond lists, and in that case you WOULDN'T join it to 
its _atom_site list.

> Anyway, I get the picture and will soldier on.  It'd be nice to hear
> what the dictionary maintenance group have to say for themselves.

Macquarie Dictionary - maintain: to preserve.


cheers

Nick

--------------------------------
Dr N. Spadaccini, Head of School

School of Computer Science & Software Engineering
The University of Western Australia
35 Stirling Highway
CRAWLEY, Perth,  WA  6009 AUSTRALIA

CRICOS Provider Code: 00126G

voice: +(61 8) 6488 3452
fax:   +(61 8) 6488 1089
w3:    www.csse.uwa.edu.au/~nick

email: head@csse.uwa.edu.au
(Mail to "head" is for official correspondence and is accessible to 
several others, in particular my Administration Officer/PA).

email: nick@csse.uwa.edu.au
(Mail to "nick" is for confidential, personal and trivial correspondence,
and is accessible only to me).


_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers