Similarly, it is possible for one save a metadatum with the ``wrong'' type-that is to say, a type different from (and not a subclass of) that which other objects expect for a particular metadatum name. Such an error would likely result in a ClassCastException (as described in §2.2) when accessing the datum. Thus, it is important to be sure that metadata types are consistant between the metadata ``readers'' and the metadata ``writers''. Of course, refering to a metadatum value via a superclass of the value's type is perfectly acceptable (sometimes better) and should not cause any problems.
Of course, it would be best if these type errors could be caught at compile-time. The recommended way of accomplishing this is to subclass the Metadata object to produce a class designed for a specific schema in which the mapping of metadatum names to value types is defined. In the subclass, one could define specialized data loading methods that enforce the schema's value types. For example, one could define a method setAltitude(Double) which would save the Double argument via the String key ``altitude''. Because the method only accepts a Double argument, it enforces the proper type at compile-time. §3.1.2 illustrates an example of this technique in which a subclass of Metadata called CoordMetadata helps to encourage type safety for metadata related to Horizon coordinate systems.