checklist issue for dpack-1 validation conditions

[nmushegian]

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

[sambacha]

should there also by a version component to the validation?

[sambacha]

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).

[nmushegian]

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

[sambacha]

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

[nmushegian]

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

[sambacha]

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

this sounds much better