Error checking of attribute, etc names.

[DavidSagan]

There should be a policy in the standard in terms of nonstandard information that is put in a data file. For example, what if a reader encounters a group named offsetttt. Is this an error that should be flagged or should the reader just ignore it and thus possibly not catch errors that exist in the file?

One possible thing to do would be to say that if a data file has nonstandard information then there needs to be a prefix used to warn a reader that indeed this is nonstandard information and not just a typo. For example, if EXT: is defined to be the prefix used for custom information then a group named /data/particles/EXT:color/ would be recognized as such and could safely be ignored. Similarly, the prefix could be used for nonstandard attributes.

[ax3l]

Thank you for the question/proposal!

Related to #115, this depends on where something and what is added. For groups, the openPMD standard (and readers & validators) are only auto-interpreting listings inside the basePath for iterations and groups inside meshesPath for mesh records and particlesPath for particle records. Outside those, groups can be freely placed.

For data sets, they are interpreted only inside meshesPath and particlesPath and within the groups spanned by vector/tensor records. All additional data sets are also fine to add since they are ignored as well which basically requires them to be placed outside the interpreted paths. This has been clarified in the 1.0.1 revision of the standard.

For attributes, one can always add more and they are ignored.

Since we improved the recommendations and additions in 1.0.1 I mark this as a question for now. If we really want to add an (additional) markup to ignore additional entries we would need to add this. Since this only affects additional groups and data sets in a file, I would propose to rather add an attribute such as openPMDignore rather than a naming convention since it is less intrusive to data writers.

[ax3l]

Offline discussion: we will move this to postponed for 2.0.
It's likely actually a (clever) tooling issue and not a standard issue.