checklist issue for dpack-1 validation conditions
isValidType and isValidObject
- [ ] typenames are mixedcase alphanumeric plus underscores
- [ ] typenames start with capital letter isValidObject
- [ ] objectnames are mixedcase alphanumeric plus underscores
- [ ] objectnames start with lowercase letter isValidPack
- [ ] typenames are equal to the key of the type in
types - [ ] objectnames are equal to the key of the object in
objects
isValidPack
- [ ] typenames and objectnames equal the keys used to name the descriptor objects in the pack
- [ ] Has “network”
- [ ] “network” is a string
- [ ] “network” is not “mainnet” (suggest “ethereum”)
- [ ] Has “format”
- [ ] “format” is a string
- [ ] “format” is “dpack-1”
- [ ] Has “objects”
- [ ] “object” is a (JSON) object
- [ ] Has “types”
- [ ] “types” is a (JSON) object
should there also by a version component to the validation?
Just to clarify, i am not referring to format/dpack-1 rather a versioning scheme that takes into account direct dependencies of the project (namely typescript and ethers).
This issue is for defining well-formed dpack-1 files, for versioning issues related to this particular javascript dpack library please open a separate issue
This issue is for defining well-formed dpack-1 files, for versioning issues related to this particular javascript dpack library please open a separate issue
@nmushegian ahh I was inferring from isValidPack to imply that this dpack is usable whereas it is more so this dpack is compliant with the specification, i.e. maybe isCompliantPack may be less ambiguous as to its value of measurement. apologies.
Can we separate out the schema from the current definition location to its own json schema file? we can use regex (patterns in json schema format) to validate + can be listed on https://www.schemastore.org/json/
Here is an example (note this is not actually a proper json schema file just quick example): https://github.com/sambacha/dpack/blob/93cc887459cd3d8dd5b3a63f8958531e19e3995d/spec/dpack-1.schema.json
regex patterns for validation of address and bytecode are provided. Using patterns can do all off the items in isValidType and isValidObject
To avoid confusion I think we might just remove schemas altogether and validate each possible error case directly, since a proper spec needs distinct error codes anyway
I think I will use isWellFormed everywhere since that is all that the dpack-1 spec actually is
To avoid confusion I think we might just remove schemas altogether and validate each possible error case directly, since a proper spec needs distinct error codes anyway
I think I will use
isWellFormedeverywhere since that is all that the dpack-1 spec actually is
this sounds much better