[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: _atom_site_aniso_label is broken
- Subject: Re: _atom_site_aniso_label is broken
- From: James Hester <jrh@xxxxxxxxxxxx>
- Date: Mon, 20 Jun 2005 17:07:00 +0900
- In-Reply-To: <Pine.LNX.4.62.0506201352580.1008@mostaccioli.csse.uwa.edu.au>
- References: <1118992457.18478.123.camel@anbf10><Pine.LNX.4.62.0506171602410.8371@mostaccioli.csse.uwa.edu.au><1118998435.18478.173.camel@anbf10><Pine.LNX.4.62.0506201006460.1008@mostaccioli.csse.uwa.edu.au><1119244417.23197.73.camel@anbf10><Pine.LNX.4.62.0506201352580.1008@mostaccioli.csse.uwa.edu.au>
As the Bearded One is maintaining a Delphic silence, let me summarize where I think we're at: I state that a (any?) reading of the DDL1.4 spec implies that _atom_site_aniso_label is broken. Nick explains that the parent/child relationship between _atom_site_aniso_label and _atom_site_label means that they can be used as keys to join/split loops even during validation, consequently solving the list_mandatory and _list_reference problem. Now I pick up the ball again: This database joining behaviour is obviously desirable, and I'm happy to go with whatever is standard, but *where* is this described? Shouldn't this be mentioned in a standards document somewhere? Why is the 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? ================ data_category _definition ; Character string which identifies the natural grouping of data items to which the specified data item belongs. If the data item belongs in a looped list then it must be grouped only with items from the same category, but there may be more than one looped list of the same category provided that each loop has its own independent reference item (see _list_reference). data_list_link_child _definition ; Identifies data item(s) by name which must have a value which matches that of the defined item. These items are referred to as "child" references because they depend on the existence of the defined item. ; _name '_list_link_child' _category list_link_child _type char _list both data_list_link_parent _definition ; Identifies a data item by name which must have a value which matches that of the defined item, and which must be present in the same data block as the defined item. This provides for a reference to the "parent" data item. ; _name '_list_link_parent' _category list_link_parent _type char _list both data_list_mandatory _definition ; Signals if the defined item must be present in the loop structure containing other items of the designated _category. This property is transferrable to another data item which is identified by _related_item and has _related_function set as 'alternate'. data_list_reference _definition ; Identifies the data item, or items, which must be present (collectively) in a looped list with the defined data item in order that the loop structure is valid. The data item(s) identified by _list_reference provides a unique access code to each loop packet. Note that this property may be trans- ferred to another item with '_related_function alternate'. ; _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]
- Follow-Ups:
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- References:
- _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Re: _atom_site_aniso_label is broken (James Hester)
- Re: _atom_site_aniso_label is broken (Nick Spadaccini)
- Prev by Date: Re: _atom_site_aniso_label is broken
- Next by Date: Re: _atom_site_aniso_label is broken
- Prev by thread: Re: _atom_site_aniso_label is broken
- Next by thread: Re: _atom_site_aniso_label is broken
- Index(es):