Some questions that need to be considered

[DavidSagan]

Here (in fairly random order) are some questions that need to be thought about and discussed. Feel free to add or answer!

• Should the Standard be case sensitive? (my vote is Yes!)
• How to handle controllers in the Standard? Say a power supply controlling a set of quad strengths. And it should be possible for controllers to control parameters of other controllers.
• How to handle custom information in the Standard? For example, add blueprint IDs to elements. One idea is to list in the lattice file the names of the custom element types, parameters, etc. One thing to avoid is to treat everything that is not recognized as custom information. This is bad since misspelling cannot be caught.
• For each schema format (YAML, JSON, etc.), there needs to be a documented standard on how to encode a lattice in the format. The lattice standard itself should be schema format agnostic.

[ax3l]

Should the Standard be case sensitive? (my vote is Yes!)

Sounds good. Tracked in #10

How to handle controllers in the Standard? Say a power supply controlling a set of quad strengths. And it should be possible for controllers to control parameters of other controllers.

Good question - we could define later on some kind of templating (e.g., definining constants) or delegate this fully to the file format, e.g., someone using template engines like Jinja on text files in YAML/TOML/JSON/etc. My current feeling is that having some support for constants (maybe basic math...?) could be helpful eventually, but delegating to implementations might be ok as well as long as inputs stare "sharable" (e.g. a script that creates a lattice standard file).

How to handle custom information in the Standard? For example, add blueprint IDs to elements. One idea is to list in the lattice file the names of the custom element types, parameters, etc. One thing to avoid is to treat everything that is not recognized as custom information. This is bad since misspelling cannot be caught.

I think there will be many additions on the properties of the lattice and elements, so we should similar as in openPMD, only defined required and defaulted attributes and let people add more (e.g., color, design file of an element for visualization, numerical models used, etc.). We could later on, when there are enough additions, again do "extensions" that we document/standardize for topics like visualization, numerical tracking, etc.

I have to think how to address your comment on misspelling - I mean for required and defined attributes, we will have validators. For misspelling of defaulted attributes we could have a strict mode in validation tools that warns on every unknown attribute.

For each schema format (YAML, JSON, etc.), there needs to be a documented standard on how to encode a lattice in the format. The lattice standard itself should be schema format agnostic.

I think if we define the standard well as list of dictionaries/maps (structs) and lists (nested tree), then we can use in implementations frameworks like Pydantic et al. to encode and format/serialize this into YAML/TOML/JSON/XML/etc. automatically.