Common defaults are defined, but the goal is to eventually allow these to be overridden by alternative choices or even algebraic expressions in the future, once more molecular simulation packages support general expressions.
... future extensions to the specification will support point multipoles, point polarizable dipoles, Drude oscillators, charge equilibration methods, and so on.
Support for other Lennard-Jones mixing schemes will be added later: Waldman-Hagler, Fender-Halsey, Kong, Tang-Toennies, Pena, Hudson-McCoubrey, Sikora.
Later revisions will add support for additional potential types (e.g., Buckingham-exp-6), as well as the ability to support arbitrary algebraic functional forms
Later revisions will also provide support for special interactions using the <AtomPair> tag
Later additions will add restrained electrostatic potential fitting (RESP) capabilities.
Later revisions will add support for additional potential types and the ability to support arbitrary algebraic functional forms. If the potential attribute is omitted, it defaults to harmonic.
Some other details are now out of date
Allowed values for units are given in simtk.unit (though in the future this may change to the more widely-used Python pint library).
or simply marked TODO
Add link to complete open specification of OEAroModel_MDL aromaticity model.
Should we have a separate <Metadata> or <Provenance> section that users can add whatever they want to?
or were nascent ideas that have not made it in and likely will not in the near future
Future additions will provide options for intelligently fragmenting large molecules and biopolymers, as well as a capping attribute to specify how fragments with dangling bonds are to be capped to allow these groups to be charged.
None of these should be in this or any specification. It should be about what is supported and how to implement those things. Until extensions are made, they should not be dangled as a carrot. (There are other ways to communicate this now that the organization is larger - roadmaps, user-facing documentation, etc.)
There are a number of promises made and discussions of future work in the specification.
Some other details are now out of date
or simply marked TODO
or were nascent ideas that have not made it in and likely will not in the near future
None of these should be in this or any specification. It should be about what is supported and how to implement those things. Until extensions are made, they should not be dangled as a carrot. (There are other ways to communicate this now that the organization is larger - roadmaps, user-facing documentation, etc.)