How do GJXDM and NIEM handle imprecise dates?

There is no perfect strategy for handling incomplete or partial dates within the GJXDM and NIEM. However, different options do exist for different circumstances. Most of the date fields are of type ''xsd:date'' whereas for example a number of our entities can include only the year. As an example, consider the case where a license plate registration year is stored only as a year. In GJXDM and NIEM there is VehicleRegistration/RegistrationEffectiveDate. For this example there are two options:

  1. Just use 01-01-XXXX and let the receiver know out of band that the month and day are unreliable. An advantage of this approach is that it doesn't require any schema changes and thus the data are more easily exchanged. Disadvantage is that it's rather inelegant and confusing.
  2.  Extend the schema to add a field of type ''gYear'' in the appropriate spot. This would require creating a local extension of PropertyRegistration, then a local extension of VehicleRegistration to use the PropertyRegistration base type. (VehicleRegistration could be extended directly but just for the sake of argument I'll put it in exactly the same hierarchy.) Then if VehicleRegistration is encapsulated in a Vehicle, type substitution must be used in the appropriate Vehicle entity. The advantage is that this way is more exact; disadvantage is that it requires much more work and has local extensions which harm interoperability.

NLETS dealt with a similar problem in which the dates only included the year, but because of the legacy data there was also the possibility of receiving several other textual values, as well as an inability to know the data while creating XML. Therefore they created an element in our namespace of type TextType and implemented using cascading extension. If properly documented as a business rule, the full date element can probably be used in the Registration situation.

However, one should be wary of implications if more exact data could be provided in the future. One runs the risk of having some exact dates, and some with 01-01 as a space holder. Then it is impossible to know if the registration was actually as of January 1, or if the Month/Day were unknown. Keep in mind that type substitution may not be appropriate here because one can only substitute with a type derived from the expected type.

Another option which would allow avoiding extension but more clearly communicating the data in the element is to leverage the comment Text metadata attribute to communicate that the month/day is unknown. The choice depends largely on the implementation circumstances. It's generally better to ensure that the content of the element will be unambiguous and err on the side of an additional extension rather than risk misinterpretation.