update spatial data schema

[CagtayFabry]

Changes

• update core/geometry/spatial_data schema to support >2 dimensional arrays as xarray.DataArray
• add wx_shape validation support for core/data_array
• create manifest version 0.1.1
• update manifest script

Related Issues

Closes # (add issue numbers)

Checks

• updated CHANGELOG.rst
• updated tests
• updated doc/
• update manifest file

[github-actions]

Unit Test Results

       1 files  ±0         1 suites  ±0   2m 4s ⏱️ +31s
1 948 tests +4  1 948 ✔️ +4  0 💤 ±0  0 ❌ ±0 

Results for commit 61c3e60. ± Comparison against base commit 8a79f5a.

♻️ This comment has been updated with latest results.

[codecov]

Codecov Report

Merging #655 (61c3e60) into master (8a79f5a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master     #655   +/-   ##
=======================================
  Coverage   96.08%   96.08%           
=======================================
  Files          91       91           
  Lines        5895     5906   +11     
=======================================
+ Hits         5664     5675   +11     
  Misses        231      231           

Impacted Files	Coverage Δ
weldx/asdf/util.py	90.13% <ø> (ø)
weldx/asdf/constants.py	100.00% <100.00%> (ø)
weldx/tags/core/data_array.py	100.00% <100.00%> (ø)
weldx/tags/core/geometry/spatial_data.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8a79f5a...61c3e60. Read the comment docs.

[vhirtham]

Something I am asking myself now is how the standard version and the schema versions are tied together:

If I modify another schema from version 0.1.0 to 0.1.1, will the standard still remain at 0.1.1 or does it bump to 0.1.2 since it is different from the previous 0.1.1? Or does the schema version automatically raise from 0.1.0 to 0.1.2 skipping 0.1.1. I guess the latter case makes more sense and the increments of the standard version are always tied to a new standard release (independent from a weldx release). So all schemas that are modified during a standard release have the same version number as the standard regardless of their previous version number.

[vhirtham]

Seeing this gets me thinking (also in the context of the GerericSeries) that the wx_shape validator should probably be able to deal with dimension names when used in conjunction with a data_array schema. For example, instead of [..., 3] we could write [..., c=3]. The latter case would express "any number of dimensions with arbitrary shape, but c must have shape (3,)" I think this would simplify things a bit since we do not need to define a coordinate order to fulfill the requirement. Maybe we should give this a different name (wx_coordinate_shape?) to avoid confusions.

[CagtayFabry]

agreed, in general I think it would be a good addition to have a powerful validator for xarray structures

the overall structure and implementation probably needs some planning

[vhirtham]

Should I create a new issue as reminder?

[CagtayFabry]

yes that never hurts 😉

[CagtayFabry]

Something I am asking myself now is how the standard version and the schema versions are tied together:

If I modify another schema from version 0.1.0 to 0.1.1, will the standard still remain at 0.1.1 or does it bump to 0.1.2 since it is different from the previous 0.1.1? Or does the schema version automatically raise from 0.1.0 to 0.1.2 skipping 0.1.1. I guess the latter case makes more sense and the increments of the standard version are always tied to a new standard release (independent from a weldx release). So all schemas that are modified during a standard release have the same version number as the standard regardless of their previous version number.

My idea for now was the following:

• I only consider a standard version as released when it has been tagged/published to pypi/conda
• right now I consider the standard version 0.1.1 as in development, meaning it only exists here on master and can change/break until the release
• once released, no changes to the standard (or old schemas) are allowed

So right now we can gather all the work we do on schemas under the 0.1.1 version (or rename to 0.2.0 if we make big changes) here on master.
We just should rely on this to be stable until the release.

[vhirtham]

Something I am asking myself now is how the standard version and the schema versions are tied together:
If I modify another schema from version 0.1.0 to 0.1.1, will the standard still remain at 0.1.1 or does it bump to 0.1.2 since it is different from the previous 0.1.1? Or does the schema version automatically raise from 0.1.0 to 0.1.2 skipping 0.1.1. I guess the latter case makes more sense and the increments of the standard version are always tied to a new standard release (independent from a weldx release). So all schemas that are modified during a standard release have the same version number as the standard regardless of their previous version number.

My idea for now was the following:

• I only consider a standard version as released when it has been tagged/published to pypi/conda
• right now I consider the standard version 0.1.1 as in development, meaning it only exists here on master and can change/break until the release
• once released, no changes to the standard (or old schemas) are allowed

So right now we can gather all the work we do on schemas under the 0.1.1 version (or rename to 0.2.0 if we make big changes) here on master. We just should rely on this to be stable until the release.

So in this case, schema version numbers are not coupled to the standard version? Means, if the standard changes from 0.1.5 to 0.1.6 we can still have schemas that increase from 0.1.0 to 0.1.1?

[CagtayFabry]

Something I am asking myself now is how the standard version and the schema versions are tied together:
If I modify another schema from version 0.1.0 to 0.1.1, will the standard still remain at 0.1.1 or does it bump to 0.1.2 since it is different from the previous 0.1.1? Or does the schema version automatically raise from 0.1.0 to 0.1.2 skipping 0.1.1. I guess the latter case makes more sense and the increments of the standard version are always tied to a new standard release (independent from a weldx release). So all schemas that are modified during a standard release have the same version number as the standard regardless of their previous version number.

My idea for now was the following:

• I only consider a standard version as released when it has been tagged/published to pypi/conda
• right now I consider the standard version 0.1.1 as in development, meaning it only exists here on master and can change/break until the release
• once released, no changes to the standard (or old schemas) are allowed

So right now we can gather all the work we do on schemas under the 0.1.1 version (or rename to 0.2.0 if we make big changes) here on master. We just should rely on this to be stable until the release.

So in this case, schema version numbers are not coupled to the standard version? Means, if the standard changes from 0.1.5 to 0.1.6 we can still have schemas that increase from 0.1.0 to 0.1.1?

yes those are independent (and I would prefer to keep the changes in schema versions also following the semantic versioning for themselfes)

The coupling to the 'standard' version is only defined by the listing in the manifest file