[QUANTITY] Pulling it all together - missing some things

David Berry dsb at ast.man.ac.uk
Mon Jun 2 04:10:47 PDT 2003



On Fri, 23 May 2003, Brian Thomas wrote:

>  	David, all,
>
> 	After reading this, I saw that it is missing some important  meta-data. To illustrate,
> 	I fall back on XDF, where "quantity" looks like "parameter" which holds one or more
>         "values". Parameter has the means to specify things like inequalities and special
> 	computer-oriented meta-data like NaN, which you can see in this snippet of the
> 	XDF dtd for example:
>
> <!ELEMENT value (#PCDATA)>
> <!ATTLIST value
>         valueId ID #IMPLIED
>         valueRef IDREF #IMPLIED
>         special (infinite | infiniteNegative | noData | notANumber | underflow | overflow | disabled) #IMPLIED
>         inequality (lessThan | lessThanOrEqual | greaterThan | greaterThanOrEqual) #IMPLIED
>         positiveErrorValue NMTOKEN #IMPLIED
>         negativeErrorValue NMTOKEN #IMPLIED
> >
>
> 	You already have errors taken care of, but are missing the "special" and "inequality"
> 	stuff. Special numbers are those which the computer may represent by a certain string,
> 	say "-9.99" but wont be recognizable as "notANumber" without the meta-data to point it out.
> 	Ditto for doing any "censored" data that involves upper/lower - limits. This is handled by
> 	the "inequality" meta-data.
>       ...

The document I produced describing the Starlink approach to Quantity was
intended to outline the main points of the scheme. As you say, there are
many other points which it doesn't mention, such as bad value handling
and documenting limits on the numerical quantities. There are also some
others such as how to format and unformat values, preferred labels, etc.
I kept all these things out in order to simplify the document and focus
attention on the principle of producing a hierarchy of classes describing
different physical domains.

To answer your two specific points:

1) Bad value handling: for numerical values in memory we use agreed bit
patterns to represent "missing" or "bad" values. These bit patterns are
in general specific to the machine architecture. For transportation
between machines, we use a text-based format in which an agreed string
("bad") is used to represent bad numerical values.

2) Data limits: Each Domain can (optionally) have a specified upper and
lower bound outside of which values are treated as if they were "bad". I
agree that in general, you may want to specify constraints in a more
general way, but as yet we have found no pressing need for it in the
applications we have produced.


David



More information about the dm mailing list