Re: [ddlm-group] _enumerated_set.table_id

Hi James,

 

Yes, we agree that _enumeration_set.table_id can be dropped.  I am uncertain whether we agree about whether it should be replaced with something else.

 

I am prepared to accept these limitations on the data types that can be defined by a DDLm dictionary (including DDLm itself), if indeed DDLm itself and the other existing DDLm dictionaries can be expressed adequately under such constraints:

 

- The allowed types of values within a list cannot depend on their position in the list

- The allowed types of values within a table cannot depend on their associated keys

 

These assign primacy to categories / loops for defining complex, heterogeneous data, so that it is unnecessary (I think) to be able to define data types that use lists and / or tables analogously to C structs.

 

I am inclined to think that one of the greater weaknesses of the 2012 version of the DDLm dictionary is its provisions for defining complex data types.  They are somewhat inconsistent, and the provided definition text is unclear about exactly how one would go about defining complex data.  Moreover, if _type.dimension is intended to be the primary vehicle for defining complex internal structure then it must bear the weight of an entire schema language.  That seems to be exactly what it’s trying to do, but the details of that language are by no means adequately documented, and it seems an odd approach given that it’s hosted inside another language that itself can serve as a schema language.

 

This is what I think we should do:

 

1. Remove _enumeration_set.table_id.  It doesn’t work well for its intended purpose.

  

2. Redefine _type.dimension so that it is used only to specify the dimension(s) of values of items having _type.container in { 'List', 'Array', 'Matrix' }.  Relieve it of any responsibility for defining element types.  Possibly remove the ability to define ragged multi-dimensional arrays (which conflict with the proposed limitation that allowed types of values within a list cannot depend on their position in the list).

 

3. Clarify that when _type.container has value 'Table', _type.contents defines the characteristics of the *values* in the table.

 

4. Add a replacement mechanism to define constraints on table keys.  It might be sufficient, and consistent with the apparent intent of the current dictionary, to establish a parallel to the _enumeration_set category for constraining key values, maybe _key_enumeration_set.  It would be a smaller change at the dictionary level, however, to add a mechanism by which constraints on key type could be defined by reference to the type of another item (see also next).

 

5. Add a mechanism to allow items' content type to be defined by reference to another item.  This could be signaled by a new code for _type.contents, with a new attribute defining which other item’s type is to be used.  I don’t think that the existing contents code 'Inherited' can serve this purpose, but perhaps I’m mistaken.

 

Allowing types of keys / values to be defined by reference to the types of other items raises the possibility that dictionaries will occasionally want to define items solely for the purpose of defining their content type for reference by other definitions.  I don’t think this is harmful, but it might be best supported by a new value for _type.purpose, as demonstrated below.

 

If all those changes were implemented then the definition for DDLm_import.get might be revised like so:

 

    _type.purpose             'Import'

    _type.container           'List'

    _type.contents            'Text'

    _type.keys                'ByReference'

    _type.key_type_reference  'import.get_key_type'

 

That would require addition of a new attribute to category IMPORT, its definition containing the following (among other necessary attributes not shown):

 

save_import.get_key_type

    # ...

    _type.purpose             'Internal'  # New value

    _type.container           'Single'

    _type.contents            'Code'

 

     loop_

    _enumeration_set.state

    _enumeration_set.detail

        'file' 'filename/URI of source dictionary'

        'save' 'save framecode of source definition'

        'mode' 'mode for including save frames'

        'dupl' 'option for duplicate entries'

        'miss' 'option for missing duplicate entries'

save_

 

Additional attributes needed in category TYPE would be _type.keys (accepting the same values as _type.contents where those values describe string data), _type.key_type_reference (containing the _definition.id of the referenced item), and _type.contents_type_reference (not demonstrated; analogous to _type.key_type_reference).

 

 

John