Discussion List Archives

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

Re: [ddlm-group] Task II: autogenerate a test for linked items

  • To: ddlm-group <ddlm-group@iucr.org>
  • Subject: Re: [ddlm-group] Task II: autogenerate a test for linked items
  • From: James Hester <jamesrhester@gmail.com>
  • Date: Mon, 22 Oct 2018 16:44:03 +1100
  • DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;h=mime-version:references:in-reply-to:reply-to:from:date:message-id:subject:to; bh=PfuiGbYbeZ3ot7ryp5Gxjn62oLZvOIBk5RbiDRvRDPI=;b=LmX/Qr2RtTuwN+Yij9cKheYh+KOdgr53DhYlkKrG2koDTUGjzRHNcBhLb3zO9HNK+upLjYa5Q5PfRSb45nBzw9/YLU7O/eqqxTj+Kwp8GeKc+IraR50MqU7OcwxH+athGyLSg9XINl2wx3SwtlNZ7NS2jTWnOmQeBadUgI+evjBN9AXtgI4ho81RemX+9ivGKp6MWwhG9FhsM1x3wz56UGHPv7qRIZfGGqPgBVR56ApkftKMMTyplbtVH2r7I2A/+H5A0qAqM5jbLvjSB2yxMjy2vxq4T72jrdlEEgu+uh7Vm0qYNMiQeX4hUK6hEX0Vvdu+DbXHs74oO09akXqm3g==
  • In-Reply-To: <CAM+dB2exOzb7+V=-TRv9NCdqTPyQqDq9EjFaUJH61Nt2nELZ-A@mail.gmail.com>
  • References: <CAM+dB2exOzb7+V=-TRv9NCdqTPyQqDq9EjFaUJH61Nt2nELZ-A@mail.gmail.com>
Well, here is one answer to the task:

1. View a DDL dictionary in what I shall blithely call a 'canonical' form: that is, with no save frames and every category supplied with a child data name of _definition.id. This is how DDL2 semantically views DDL2 dictionaries.  Each save frame then simply corresponds to filtering the 'canonical' form by the _definition.id.

2. Then our dREL method for _method.expression in the DDLm attribute dictionary is generating dREL that will be executed in the context of a METHOD category with values populated by the domain dictionary. The METHOD category in the canonical presentation is a single table indexed by compound key (_method.definition.id, _method.id).  We can use that _method.definition.id to index into the NAME table to find linked_item_id, and then use the resulting value to index into the table for NAME again, to finally end up with the category.  Using the short cut that I have proposed for resolving object references where a linked data name of the category key is in scope, the resolve_variables function can be expanded to read:

Function resolve_variables(template: [Single,Text]) {
    # Bindings to instance data are available in functions too
    object = name.object  
    category = name.category
    linked_name = name.linked_item_id
    linked_category = name[linked_name].category_id
    linked_object = name[linked_name].object_id
    dataname = category + "." + object
    template = substitute(template,"$dataname",dataname)
    template = substitute(template,"$object",object)
    template = substitute(template,"$category,category)
    template = substitute(template,"$linked_category",linked_object)
    template = substitute(template,"$linked_object",linked_object)
    resolve_variables = template
}

and the very inefficient (because it loops over the parent values for every value to check) dREL generating method itself becomes:

# ... previous sections
link_template = """
found = 'False'
loop q as $linked_category {
    if ($dataname == q.$linked_object) found = 'True'
    }
return found
"""
if (method.id == 'linked') {
    method.expression = resolve_variables(link_template)
}

I feel confident that this approach can work for all validation cases, and so John's deduction is correct, that there is no need to create new built-in functions and dREL contexts in order to perform validation.

The question then becomes, which approach is preferable?  Or is there a 3rd way?  Here is how I summarise the two approaches:

"Original proposal": Introduces new built-in functions for reflection and stipulates an expanded dREL environment for 'Validation' leading to increased complexity in full dREL implementations. Validation checks can be organised, documented and hidden away as self-contained definitions in separate dictionaries. Routine dREL and dictionary users are unaffected.

"Minimum-change proposal": A single useful new built-in function for substitution is created but otherwise dREL is unaffected. Validation checks are auto-generated for each domain dictionary dataname from code in the DDLm attribute dictionary.  Operation of validation is not easily followed by casual readers, arranging dynamic execution of auto-generated code will present issues for non-dynamic languages, DDLm attribute dictionary enhanced with a single long method to generate all validation methods.  As validation methods are ephemeral, documentation is either within the dREL itself or separate from the dictionary.

So...I still prefer the original proposal.  What do others think?  Is the auto-generation route appealing?

James.
 

On Fri, 19 Oct 2018 at 13:13, James Hester <jamesrhester@gmail.com> wrote:
This email seeks an autogenerated test for checking that values of a data name that is linked, via _name.linked_item_id, to another data name, only take values taken by that data name. I have not been able to construct such a test, because I can't loop over the values of a dataname from a different category, because I cannot look up the category that a given dataname belongs to at test generation time (because I only have access to the contents of a single domain dictionary definition in the standard dREL execution environment). So this is more of a challenge: please come up with such a test, or a way to make such a test work. In the sketch of a solution below, you need to somehow either find the values of $linked_category and $linked_dataname_object at test generation time, or instead directly access those values at test execution time.

# ... previous sections
link_template = """
found = 'False'
loop q as $linked_category {
    if ($dataname == q.$linked_dataname_object) found = 'True'
    }
return found
"""
if (method.id == 'linked') {
    method.expression = resolve_variables(link_template)
}


--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148


--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/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