About the verify commands:

Putting the verify functions (which are runtime code) in the model
description makes a mockery of the separation into modules. For languages
that do not allow the direct execution of code strings it requires a
generation step anyway to get the verify functions from the pure
description. And it will be difficult to do across languages, or at best
depend on very idiosyncratic features of each language.

As a better alternative, I propose making the verify functions (e.g.
verifyName(value) and verify('name',value)) into static functions of the
API classes. This should allow verification to be done without having an
existing object, no? The functions can then be generated with the normal
machinery like other API functions. Do you see any problems with this
approach?

For attributes with hicard!=1 (such as 'keywords') the verify function
could take either the entire list or a single element of it as its input.
Either would work, but it seems most consistent to me to do the
verification for the entire list. After all, if we are checking cardinality
constraints for other cases we might as well do it here. This would mean
sometimes having to pass a list containing a single element, and could make63.35
it a bit tricky to check a single value in some unusual cases (locard !=0).
Would this be acceptable? Do you have any comments on this point?

Finally, is there any point in having verify functions for links, seeing as
all they could do would be to check type and cardinality? I would say no,
but comments are welcome.