Ponder a native JSON serialization - #62
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #62 +/- ##
==========================================
- Coverage 61.13% 61.13% -0.01%
==========================================
Files 83 83
Lines 96370 96370
Branches 30543 30543
==========================================
- Hits 58913 58912 -1
Misses 21411 21411
- Partials 16046 16047 +1 ☔ View full report in Codecov by Harness. |
|
Odd that the design doc never mentions FitsChan, only XmlChan and YamlChan. FitsChan does include a native encoding. None of the native encodings have ever been used to the best of my knowledge (except obviously for the basic Channel class). I suppose the reason is that the only bit of software that understands the semantics of an AST object is the AST library itself, which already has the Channel class. |
Design for a new JsonChan Channel subclass providing lossless JSON serialization of AST objects (JSON syntax, AST semantics), with generated per-class JSON Schemas and a shared object/KeyMap converter reusable for a future native YamlChan encoding. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
$minReadVersion gates the envelope grammar, not the class vocabulary, so adding a new class is a MINOR bump that leaves $minReadVersion at 1. Unknown $type is always a hard error (like native astGetLoader), distinct from unknown attributes which Strict governs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Define a dedicated AST__FORMAT_VERSION constant (separate from the library version) as the single source of truth for the serialization vocabulary, enforced by a CI schema-regen version-bump guard. Record the native-format version comment as deferred future work. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The versioned thing is the Frame/Mapping object-model schema, not a file format, so the constant becomes AST__SCHEMA_VERSION. Versioning starts at 1.0.0 with no historical archaeology; major is expected to stay 1. Patch covers description/comment-only changes, minor covers new classes, attributes, or type changes; the CI check distinguishes structural from description-only schema diffs to choose the level. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Add a JsonEncoding attribute (default NATIVE) mirroring XmlChan.XmlFormat and YamlChan.YamlEncoding, as the extension point for future foreign JSON encodings such as OME-NGFF coordinate transforms (RFC 5). Only NATIVE is implemented; selecting another encoding errors. Plan Task 1 keeps and renames the YamlEncoding machinery rather than deleting it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3029557 to
cc874d4
Compare
|
We did use FITS Native form in We are using the native string form internally in Rubin data but if we could put both the FITS-WCS approximation and the full Native form in the same FITS header and have DS9 pick out the native form in preference, that might be an interesting approach for some users. The JSON form proposed here is me wondering whether it would be more straightforward for us to write JSON into our JSON models directly instead of a blob, and then have schema validation for the entire model. cc/ @TallJimbo |
2 participants
This would also make native YAML pretty straightforward.
This is purely a spec at the moment. No implementation to look at.