[Dev] [Scientific] .get inifinity questions

[jb at integralive.org]

Hi,

>
> We will use this datatype in the XML to represent ANY floating point
> number regardless of the value of the attributeTypeCode element.
>
> (Jamie: This would probably be a good thing to have in the wiki, right?

Absolutely. I think the appropriate place is in the 'Technical Overview'
under 'XML storage'. This section needs expanding, as do some of the
others.

>> perhaps the "code" attribute
>> can be removed since we are expanding it out in the XML. perhaps <item
>> name="double"><description>blah</description></item> would be better?
>>
> There is actually two (three) questions here:
>
> 1. Is it necessary to include the code of the lookup in the XML?

No. In the database, for the lookup tables, both 'code' and 'name' fields
are guaranteed to be unique. The integer codes are just used in the
class/module definition arrays for efficiency.

> 2. Is it necessary to include the index of the current attribute in the
>    array of attributes stored in the database?
>

It isn't 'necessary', but for the reason you give below (readability) it
is 'nice'.

> if(1 && 2)
>
> 3. Is it necessary to have the same syntax for the attribute arrays (of
>    the class) as for the values from the lookup tables (which is what we
>    have now)?
>

I think that to have the same syntax for both is actually slightly
confusing, and I think that your suggestion (below) is the right way to
resolve this.

> The attribute name 'code' I used because it represents the code used to
> fetch the value in the lookup table (each of the lookup tables in the
> database schema has an index field named #code). This is perhaps
> not necessary now as we have *not* limited the value of the lookup in
> the schema - IOW as far as the XML is concerned we take for granted that
> the lookup results in a legal value. At the time it seemed like a good
> idea to keep using the same syntax, which now, looking at it again, I
> don't think it is at all.

Agreed.

> This is what I'd like to suggest:
>
> <classTagCodes> has any number of <item>'s containging a <name> and
> <description>. None of these have any XML attributes.
>
> <aggregatedClass> has any number of xlink'ed <item>'s.
>
> All the fields that refer to an array of class attributes (in the
> database schema: class_attributes, class_attribute_descriptions, etc in
> the class_definition class and *all* the members of the
> module_definition class) have the following syntax (referring to the
> expanded array of attributes):
>
> <classAttributes>
>   <index value="0">
>      <name>freq</name>
>   </index>
>   <index value="1">
>      <name>phase</name>
>   </index>
> </classAttributes>
>
> There's a number of reasons for including the current array index, the
> most important to me is the human readability. Imagine a class
> definition with 35 attributes - if you for some reason need to look at
> the XML file an you want to check the type of certain attribute -
> without the index you'll be lost... I imagine it will also help in
> machine reading contexts, at least for large parameter spaces.
>

Yes, agreed!

best,

Jamie