Discussion List Archives

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

Re: [ddlm-group] Objectives of CIF2 syntax discussion. .. .


On Wednesday, January 19, 2011 10:13 AM, Herbert J. Bernstein wrote:
>Let's take a concrete example:  Suppose we want to use a DDLm method to
>populate _diffn_standards.decay_% in an mmCIF dictionary from the actual
>measured reflections (or, more elegantly as a long-term goal directly from
>the data in a scan of image frames).
>
>That tag cannot be used directly in a dREL method. Under David and John's
>proposed use of the alias mechanism, what aliases would have appear where
>and to what should be method itself refer, and in what save frame would it
>be defined.  Ideally, we would like to be able to have this all gathered
>into one dictionary, and the dictionary merge mechanism allows us to do
>that, so whatever we propose should not depend on the name or type of the
>dictionary.

Relying on the name of a target dictionary to choose the output names for data items is compatible with merged target dictionaries.  However many levels of merging are used, each definition ultimately comes from some self-contained dictionary, and the name of that dictionary can be used to select its data names from an alias list.

To handle merged dictionaries more transparently, a DDLm-based application might accept a priority list of root dictionary names to use in selecting output data names.  Use of such a feature pre-supposes some knowledge or assumption about the origin of the target dictionary, but the user needs to bring something to the table to be sure of getting back what he wants.  In the worst case, the target dictionary could be scanned for definitions of one of the aliased names, though such a procedure would be susceptible to error in the event of name collisions.  As a last resort, a runtime system could allow output and even input name bindings to be explicitly overridden: effectively, Import ... As ... implemented as a function of the runtime system instead of encoded in the dictionary.

As I currently understand it, on the other hand, Import ... as ... would simply assign an alias from within a dREL method's code.  Given that the code is located in the same place as alias definitions -- that is, in an item definition within a data dictionary -- I fail to see how such a statement could provide features that the alias system could not.  It is merely a difference between imperative and declarative forms, with the declarative form (aliases) currently having at least the advantages of separation from the method code, dynamic resolution, and compact support for multiple cases.


Regards,

John

Email Disclaimer:  www.stjude.org/emaildisclaimer

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://scripts.iucr.org/mailman/listinfo/ddlm-group

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

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

International Science Council 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.

Useful links