As I said I have no overlook about the implications with upcoming
back-config etc.
Well, let aside back-config, the essential issue that drives currently
hardcoded schema items is that since they're required for directory
operations (think of "userPassword" in simple bind, or "uid" and "cn" in
mapping SASL identities, or "ref" in referrals and so) hardcoding them is
an easy, safe and reliable way to ensure they're defined as expected by
the code. Otherwise, leaving them to a configuration file would require
extra checks to ensure their definition (in terms of syntax, matching
rules, constraints and so) complies with the expectations of the software.
With respect to the issue I'm raising, the point is that the objectClass
"monitor", which allows "description" and "seeAlso" (and requires "cn" and
allows "labeledURI", which already are hardcoded), is mostly based on
operational attributes, and operational attributes cannot be parsed from
schema files (unless one resorts to the "dsaschema" module; but this would
really be a nasty workaround).
So, to avoid the chicken'n'egg problem that arises when one needs to
define monitor schema before reading slapd.conf, while allowing as much
flexibility as possible, I think hardcoding well-known, standard track
attributes is a reasonable trade-off. But that's my (humble) opinion, so
here's the reason for my request for comments.