Hi John, On Fri, 2006-01-27 at 09:39 -0500, Bollinger, John Clayton wrote: > I can't authoritatively interpret the _category.mandatory_code for > you, but I can point you to > http://www.crystal.uwa.edu.au/star/StarSpecs.pdf for a formal > description of save frame semantics, including scoping. I don't know > whether it is specific enough to help, but it does say that the data > in a save frame are "insulated from" those in the surrounding data > block. I also observe that neither CIF nor STAR defines a mechanism > to reference save frame contents, though STAR does have a syntax for > referencing an entire save frame as a data value (which, I'm sure you > know, is specifically disallowed by CIF). Just to clarify what STAR is supposed to do, Volume G section 2.1.3.6 on STAR save frames and 2.1.3.9 on STAR scopes state that the scope of a save frame is all data items contained within the frame, but a save frame may reference other save frames (!). The scope of a data block includes any save frames, "and all specifications [of a data item] will be recognised when accessing the data block". I confess to not understanding what recognising all specifications might actually mean. > My take on all of this differs from yours. In the absence of clearer > semantic specifications, I have looked at save frames as > self-contained data objects, independent of their data block except > inasmuch as the block scopes their *names* and hence all references to > them. I may be reading too much into it, but I take the "insulation" > bit in the STAR docs to mean that the inside of a save frame doesn't > have a view of the surrounding data block at all. When it comes to > validation, then, I'll offer the possibility that you are misapplying > the DDL rule: Vol G apparently requires a mandatory category to appear > in a *data block* based on the relevant dictionary, but a save frame > is not a data block, so this requirement is irrelevant to individual > save frames. It is unclear whether a data block that contains a > mandatory item within a save frame thereby satisfies the mmcif > requirement, but the intent seems to be that it should do. I find this eminently reasonable logic, and this was my own starting position. Where I am now, after trying to write a generic validator for CIF/DDL, is to view the object to be validated as the combination of the enclosing datablock and the specific save frame (so the enclosing data block acts as a global block). The only exception to this rule is parent-child validation, which requires access to the entire data block: e.g. as _item.category_id is a child of _category.id, you have to access all category definition save frames in order to check that a given _item.category_id corresponds to a category which has been defined in the dictionary. A further exception would be _category.mandatory_id if it were to mean "this category appears somewhere in the datablock proper or in at least one save frame", which is one possibility you raise. > After all that, I'm not sure whether I have addressed your core > concern about whether _item_description and _category_description are > appropriately defined. My apologies if I have not. Discussion of these issues is very helpful, as it is just me and Volume G at the moment. Best wishes, James. -- _______________________________________________________________________ James Hester, ANBF KEK e-mail: jrh@anbf2.kek.jp Oho 1-1 Phone: +81 298 64 7959 Tsukuba, Ibaraki 305 Fax: +81 298 64 7967 Japan ________________________________________________________________________ _______________________________________________ cif-developers mailing list cif-developers@iucr.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Copyright © International Union of Crystallography
IUCr Webmaster