Axiom TODO
Those are specification and conceptual things to figure out.
Coding/development tasks are not here. Use OpenProject 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