-
Notifications
You must be signed in to change notification settings - Fork 29
Roadmap
Indivdiual changes are being proposed and discussed as GitHub issues. New ideas are welcome and appreciated!
Click here to see a list of issues milestoned for 1.6.0.
This release has two themes:
-
Tag cleanup. Remove optional tags from the standard as well as tags related to abandoned experimental features. Clarify the standard by removing or reclassifying all currently optional tags.
-
Reconcile with the Python reference implementation. The reference implementation has behaviors and limitations that are not spelled out in the standard, so we'd like to clarify the standard where necessary.
These changes were originally planned for version 2.0.0 but the broadening scope of that release has motivated us to plan an additional 1.x release, so that we can move the transform tags to a new repository sooner.
The transform tags have been an optional extension to the core standard that supports serialization of data transforms. They've been under rapid development and have necessitated several releases of the ASDF Standard.
In order to help stabilize the standard, and make development of the transforms more convenient, we intend to move the transform tags to a separate repository and version their extension independently.
The fits-1.0.0 tag enables serialization of a FITS file inside of an ASDF file. This is another optional extension and will be moved to an independent repository.
This is an experimental feature that sought to make serialization of subclasses more convenient by reusing the superclass's schema, with some additional metadata appended to inform the library of which subclass to instantiate. This feature has some drawbacks. For one, the name of a class or subclass is an implementation detail that is probably not meaningful to other ASDF implementations. Another drawback is that by using a generic schema for multiple subclasses, we are not able to validate as strictly as we could with separate schemas – for example, if subclass A requires property "foo", but subclass B does not, we can't make the property required because both objects must validate against the superclass's schema. This tag will be removed from the standard.
The schema for the constant-1.0.0 tag contains the following description:
Used as a utility to indicate that value is a literal constant.
It's unclear what use cases this tag was intended to satisfy. The reference implementation supports deserialization of the tag's object but we're not aware of any ASDF files that make use of it.
Support for the defunit-1.0.0 tag was never implemented in either of the asdf or astropy Python packages.
Support for units and quantities is essential for a scientific data format, so rather than pull these tags out into an independent extension, we intend to make support for unit-1.0.0 and quantity-1.1.0 required.
Support for times is similarly essential (though the current time-1.1.0 tag includes features that may only be of interest to astronomers). This tag will become required in ASDF Standard 1.6.0, but will likely see some modification in 2.0.0.
YAML 1.1 allows complex map keys such as lists and maps, but this is not supported by the reference implementation -- Python does not support mutable objects as dict keys, so an ASDF file containing such a key will fail on read.
Our schema format includes a default property but the standard is vague on how that property is to be used. The current behavior of the reference implementation is to remove default values from the ASDF tree before writing the file.
The standard gives no indication that null values are disallowed in ASDF files, but the reference implementation removes map entries with null values before writing the file.
The YAML 1.1 spec recommends but does not require that the tag URI follow the tag: URI scheme. The reference implementation, on the other hand, requires tag:.
The standard is vague on how tag URIs should be mapped to schema URIs. This information is captured in the tag property of the object's schema, but that property is actually a validation directive and using it as an annotation in this way has undesirable side effects (and isn't documented in the standard).