...
- The location syntax of per-entity metadata SHALL conform to the Metadata Query Protocol (md-query).
- An md-query server that supports arbitrary "ad hoc" queries might is thought to be characterized as "a disaster waiting to happen."
- In what follows, a "metadata query" is not to be confused with an "arbitrary ad hoc query for metadata." The latter is not a goal advocated by this subgroup.
- An md-query server can avoid arbitrary "ad hoc" queries and still deliver significant functionality.
- In particular, per-entity metadata can be pre-computed and stored in the file system. A simple script on the server maps the
entityID
in the md-query to a metadata file in the file system.
- In particular, per-entity metadata can be pre-computed and stored in the file system. A simple script on the server maps the
- It is believed that most every aggregate of interest can be known in advance and therefore be pre-computed. This precludes having to support arbitrary "ad hoc" md-queries.
- Let users use entity attributes (or some other mechanism) to pre-register their md-queries (so that the target aggregate can be pre-computed).
- The location syntax of user-specified aggregates is an (interesting) open question.
- An online signing key (secured in a trusted HSM) is a separate issue. From a security PoV, this approach has at least two advantages of this approach are: 1) the validity window on metadata can be tightened, and 2) the human factor can be eliminated.