Axiom TODO

Last modified 27 Oct 2021 12:21 +02:00

Those are specification and conceptual things to figure out.

Coding/development tasks are not here. Use Jira for that.

High Prio

Need to do in M2/M3.

  • Finish Axiom spec document:

    • Items, values and types: Tony

      • Make sure we document that data are unordered.

    • Primitive types: Tony

      • Final list of primitive data types (axiom-types.axiom): Tony

      • Short explanation of simple type subtyping.

      • Primitive types: without prefix

        • Only built-in types from axiom-types.axiom or types from current model.

      • Qualified name datatype, rules for namespace lookup

        • axiom-types: QName (supertype URI)

    • Syntax description review: Rado

    • Augmentation and data:

    • How to implement dynamic model: shadow attributes, resource connector configuration: "dynamic" data type, decided, need to be documented

  • Complete axiom-model.axiom and other Axiom defs (for M2): Tony

  • Use of metadata in mappings: Palo

  • Metadata usage survey: Slavek

  • "Metadata for dummies": document explaining metadata, how they will work in midPoint, how they will be expressed in Axiom - and why we needed to create Axiom to support metadata. Where are we now. Can be referenced from blog, can be used in report to NGI. : Rado → Metadata in a Nutshell.

Mid Prio

Probably in midPoint 4.3.

  • Officially finalize Axiom 0.1

    • Move Axiom spec to a permanent place.

    • Review if we are not missing any major piece.

    • Annonunce to the community, blog, etc.

  • Document "dynamic" data type

  • Are primitive types (e.g. string) extendable? Can we inhering from them? Can we augment them? How will this work? : Tony

  • Enumerations

  • Heterolists: How to define them? How would they work? Make the ordered? How to make them pluggable?

    • Use of heterolists for expression evaluators

  • How will we support expressions in filter? How would we use query language at all? Or will query be special?

  • Check that Axiom is web-friendly.

  • Smooth out JSON/YAML syntax: e.g. @ns or @context?

  • minOccurs/maxOccurs or required/multivalue?

  • Final axiom-*.axiom: Tony

  • Axiom and Prism (and midPoint):

    • MidPoint resource schema and shadow attributes: will they fit? How do we deal with namespaces here?

    • Draft of prism.axiom

    • Concept of "container key" and item path.

    • Decide about deltas: "native" data structures in Axiom? Or Prism?

    • Decide about query language: part of prism or axiom?

    • Prism/midpoint: object reference and relation

    • Display properties (e.g. displayName)

    • How would midPoint associate lookup table with item definition? (e.g. locales)

  • Documentation

    • Operational items

    • Elaborate items

    • Versioning: deprecation rules, etc.

Three conceptual layers:

  • Axiom: abstract data modeling, data types, items, schema versioning, identifier, path(?), metadata

  • Prism: object, basic object structure (oid,name), containers (with identifiers), properties, object referecences, deltas, query language, polystring, expressions, item display properties?

  • MidPoint: IDM-specific data structures, relation, orgstruct (also in query), special expression evaluators

The question of object identifier: UUID? URI? Mapping between UUID and URI? UUID is better for local use. But we want to be Web/REST-friendly. URI/URL will be needed for that.

Is the identifier concept right? Especially the space thing, it looks like an implementation detail. Should be use something more abstract?

Low Prio

Can wait for midPoint 4.4 or even later.

  • Annotations: how would we support custom annotations in model?

  • Make Prism web-friendly (e.g. translate OIDs to URIs)

  • Transform midpoint schemas to Axiom.

  • Item path and handling of identifiers (keys)

Trivial Prio

Can wait for long time.

  • Formal specification of object lists (e.g. XML <objects> or JSON top-level lists)

  • Consider application of metadata to metadata