Discussion List Archives

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

Re: [ddlm-group] import and loops in ddlm

Dear Colleagues,

   David raises interesting points.

   1.  I think is makes dictionaries much harder to read when tags for
a single row category are required to be looped instead of being
presented as tag-value pairs, and urge a relaxation of this DDLm
rule to be more sonsistent with DDL1 and DDL2.  It is trivial to
make an automatice converter to impose the more stringent rule,
but I think it to be a mistake.

   2.  This then relates to the second issue that David raises.
If we allow unlooped presentation of tag-value pairs from looped
categories, then we will very rarely, if ever, need to loop imports.
I would urge that the few cases that might justify looping
imports be avoided.  Let us consider the specific scopes of
possible imports:

Dic 'all saveframes in the source file'
Cat 'all saveframes in the specific category'
Grp 'all saveframes in the category with children'
Def 'one saveframe containing a definition'
Att 'import attributes within a saveframe'
Sta 'import enumeration state list only'
Val 'import enumeration default value list only'

Only the last three can raise issues of looping.

Consider ATT first.  From the ddl_import_aug08.pdf presentation, slide
15, it is clear that attributes are to be brought in as tag value
pairs, and it is also clear that this example could not work if
the NAME category were required to be looped.  Fortunately for
this example, the NAME category is classified as a set, but what
are we to do if we wish to be able to write a similar example
for a dictionary item that does have a key item?  David is
suggesting that we should include the _import within the loop,
but what are we then to import -- a complete loop with the loop_?
a partial loop without the loop_ and without some of the tags?
first an import of some tags and then an import of some value?
...?  Of all of these, importing a complete loop with the loop_
seems the safest easiest to read, but if we do that we need to
permit the implicit merging or joining of the loop we import
with whatever is already in the dictionary or has been previously
imported.  That would be simple and clear and consistent with
the later handling of STA and VAL imports as complete loops
on slides 16 and 17.

Bottom line:  What I am suggesting is that the import mechaanism
automatically merge or join multiple categories/loops that
obviously should be merged or joined.  This would allow us to
pull togehter material for a single category from multiple
dictionary imports, and would use precisely the same mechanism
as has long been used in DDL1 cifs and DDL2 cifs and dcitionaries
to merge individual tag value pairs into common categories when

I think this would be a lot simpler than looping imports.

  Herbert J. Bernstein, Professor of Computer Science
    Dowling College, Kramer Science Center, KSC 121
         Idle Hour Blvd, Oakdale, NY, 11769


On Wed, 21 Jul 2010, David Brown wrote:

> I will try again to start a discussion on the DDLm dictionary as opposed to CIF3.
> The two items below indicate my interpretation of the way DDLm will deal with a couple
> of items where the practice may change from CIF1 or we need to agree on how a new
> feature is used.  I don't believe these to be controversial, but I would like to
> receive some feedback, even it you think my interpretation is correct.  I have other
> more contentious questions to raise later.
> 1. Are loops required to be present explicitly even when they contain only one set of
> items?
> -------------------------------------------------------------------------------------
> Checking the DDLm dictionary and the proof-of-concept CIF dictionary prepared by Syd,
> it seems that the answer is 'yes'.  Therefore I intend to include explicit loops for
> all dictionary items where a category key is defined.  Whether this rule can be
> enforced in data files at the CIF level is something we might discuss.  In DDL1 such
> loops have been optional, but that need not deter us from requiring them in CIFm data
> files.  However, in the dictionaries, over which we have some control, there is no
> reason why the rule should not be enforced.
> 2. Use of the IMPORT statement
> ----------------------------------------
> Since the _import statement is used to expand a CIFm dictionary by inserting the same
> piece of text in different places, _import must be executed before the dictionary can
> be used.  Therefore the _import dataname has a different function from all the other
> datanames.  During expansion, the dictionary is read as text with the reading routine
> only acting when it encounters an _import data item which it replaces with the
> designated text.  '_import' can appear anywhere in the unexpanded dictionary,
> including in a loop even though it belongs to a different category since '_import'
> will never be encountered when the loop is executed.  It can also appear in delimited
> text or as part of a list, even in a comment (though this would not normally make much
> sense).  I can see no reason why import statements may not be nested though I have not
> yet come across a situation where this might be useful.
> Comments please.
> David
ddlm-group mailing list

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.