[Dev] [Scientific] .get inifinity questions

[Henrik Frisk]

Hi Stephen,

Thanks for the feedback! See below for some comments.

> > More questions, are you using the value 0 in attributeMaxima to 
> > represent infinity? 
> 
> I don't think so. Henrik might correct me here, but 0 is just a
> placeholder here. Again, the actual values in the files will be
> populated from the database data, and we have the possibility to
> represent inf, -inf and NaN's using a double precision numerical data
> type. I guess eventually in the XML files those values will indeed be
> stored as strings.
> 
We will be using the W3 XML built-in 'double' type (IEEE
double-precision 64bit floating point datatype (IEEE 754-1985)) which
also contains the special values of; positiveZero('0'), negativeZero('-0'),
positiveInfinity('INF'), negativeInfinity('-INF'), notANumber('NaN').

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?
I'll make an entry, if you have objections or disaprove you can always
remove it ;-) )

I have changed the attributeMaxima/item/value to 20000 in the Sinus.xml
file in the svn (which is what it should have been, although, as Jamie
noted, it's not really of significance at this point). If we used a
Schema language such as RELAX NG that has support for relative data
checking it would be much simpler to, in the schema, make sure that
these mistakes wouldn't happen. But, it may not be relevant as all XML
will be machine generated.

> >  Would it not be safer to use some string to 
> > represent special values?
> > 
> > What is the meaning of the "code" attribute for "item"?  Also, what is 
> > the need for the "item" tag?
> > 
> 
> Again, Henrik may correct me, but I think that "code" corresponds to the
> lookup code used in the database, and again "0" has been used as a
> placeholder. Henrik: if this is the case, 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?

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

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)?

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. 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.

> 
> > Thanks, I think this is a good beginning!
> > 
> 
> It's great to get things moving!
> 

Thanks again for pointing these things out Stephen. The Schema is pretty
well documented (I think...) and one of the purposes of it is to have a
common reference and human readable implementation of the database
schema. The Sinus.xml is an example implementation of the Schema. If any
one fo you have comments or suggestions for the documentation of the XML
Schema, please let us know.

I will try to make these changes in the schema and the XML files ASAP.

best,

Henrik