Certain type definitions in featureTable.schema.json referred to multiple types with oneOf, where the first type did not have a name. In additon to causing trouble for generating the property reference with wetzel, this "unnamed type" was repeated several times. Now, this unnamed type is called BinaryBodyOffset.
Property reference before:
[#reference-featuretable-definitions-globalpropertyinteger]
=== featureTable#/definitions/globalPropertyInteger
An object defining a global integer property value for all features.
* **Type**: One of `object`, `integer`
* **Additional properties are allowed.**
Property reference after:
[#reference-featuretable-definitions-globalpropertyinteger]
=== featureTable-definitions-globalPropertyInteger
An object defining a global integer property value for all features.
* **Type**: One of <<reference-featuretable-definitions-binarybodyoffset,`featureTable-definitions-binaryBodyOffset`>>, `integer`
* **Additional properties are allowed.**
where the link leads to the definition...
[#reference-featuretable-definitions-binarybodyoffset]
=== featureTable-definitions-binaryBodyOffset
An object defining the offset into a section of the binary body of the features table where the property values are stored if not defined directly in the JSON.
...
The output is still not perfect. I'm playing "whack-a-mole" with wetzel right now. But this change should be independent of that, and at least allow this sort of linking, instead of using object.
This seemed to be the only "unnamed type" for now. There are some properties that are still listed as object. Namely the ones where type constraints are established with additionalProperties - for example, statistics.classes. One could make a case for giving this a name as well. But right now, these are documented with a line
* **Type of each property**: <<reference-statistics-class,`statistics.class`>>
lilleyse
commented
2 years ago
Certain type definitions in
featureTable.schema.jsonreferred to multiple types withoneOf, where the first type did not have a name. In additon to causing trouble for generating the property reference with wetzel, this "unnamed type" was repeated several times. Now, this unnamed type is calledBinaryBodyOffset.Property reference before:
Property reference after:
where the link leads to the definition...
The output is still not perfect. I'm playing "whack-a-mole" with wetzel right now. But this change should be independent of that, and at least allow this sort of linking, instead of using
object.This seemed to be the only "unnamed type" for now. There are some properties that are still listed as
object. Namely the ones where type constraints are established withadditionalProperties- for example,statistics.classes. One could make a case for giving this a name as well. But right now, these are documented with a linewhich should be fine here.