Add Aspect Mappings

[thorsten-reitz]

Aspect Mappings are mappings that affect all cells matching a range of criteria:

• Property type: "Apply to all properties of type WidthRange"
• Convertible property type: "Apply to all properties of type Date or DateTime"
• Property name: "Apply to all properties with the name type"
• Multiple property names: "Apply to all properties with the name type or tipo or typ"
• Property type names matching a regular expression

These criteria can be combined with logical operators (and/or).

Workflow:

1. create a normal mapping cell
2. in the mapping or alignment view, right-click on the cell and select "Edit matching criteria"
3. In the wizard, by default all matching criteria will be set strict - on namespace, property name and property type.
4. Select which matching criteria are set to which matching strategy (any, compatible, ignore version, regular expression) for each of the three properties (namespace, localname, type)
5. Select whether to limit the scope of the aspect mapping through selection of (concrete) types from the schema
6. Confirm

Explanation of matching strategies:

• any: apply to all cells, regardless of value; can be set on namespace, property name and property type
• compatible: apply to all cells where a property type conversion is possible according to the conversion service as well as subtypes/supertypes, this can include going from different versions of the property; can be set on property type
• ignore version: apply to all cells where a property type is used in a different version; can be set on property type
• regular expression: apply to all cells that match the regular expression can be set on namespace, property name and property type

DoD:

• All properties affected by an aspect mapping cell need to be indicated in the schema explorer in a separate color, e.g. light blue.
• in the Mapping and Alignment views, such cells should also receive a special color and/or marking.

[stempler]

I think a good approach would also be to integrate the configuration in the entity selection page of the current cell wizard. The "aspects" are configuration done on the entity level anyway. To keep the space needed for the extra configuration low, a button could be used to switch between different "modes" and a second button to open up a dialog if a more complex configuration is required. Modes could be configurations that are expected to be commonly used plus a "custom" mode for extended configuration (added later).

Modes on type level could for instance be: strict, any, same namespace

Modes on property level could for instance be: strict, same name, same name and compatible type, custom.

Primary use case is the case when there are the same properties defined in different types that don't have the same super types in their hierarchy, so that the inheritance cannot be used to create the mapping once and be applied to all types.

Regarding the mechanism that @thorsten-reitz described there are some things that need to be clarified:

1. Where are aspect conditions applied to? Mentioned are namespace, property name and property type - does that refer to the leaf element? What about its parents (the whole property path) and the parent type?
2. What are versions and how should they be detected? (see ignore version)

My suggestion regarding 1. would be to allow one type and one property aspect for an entity (the later only if it is a property). The type aspect may contain rules regarding namespace and type name. The property aspect may contain rules regarding property name and property type that only apply to the leaf element. Specific rules regarding namespace and names may apply to the whole property path (usually ignoring groups).

[thorsten-reitz]

@stempler I like the proposal to integrate the configuration in the entity selection page of the current cell wizard, I think it simplifes usage of the aspect mappings.

On the two questions:

1. The scope is an interesting question. I had thought of using an optional set of concrete types tolimit the scope. For the moment, I would simplify the application of aspect mappings to first-level children of types, or as you suggest to all leaf types. Going forward, constructs such as AProp in BProp seem an interesting concept.
2. By version I meant that often namespaces have a version element, and we could set the matching to ignore the version element of the namespace.

[stempler]

Important aspect regarding the property path is that we can't just say that we look for properties on any path, because of the possible cycles in the structure. We need to be able to identify all the matches w/o to much effort. As long as there are no concrete use cases that require something beyond the basic property path conditions like ignoring groups and namespaces I think there is no need to invest to much here.

[thorsten-reitz]

@stempler I agree. Let's do the basic use cases we know e.g. from AdV Geographical Names and swisstopo Administrative Units and stick to those.

[thorsten-reitz]

@stempler Do you have ideas how to split this user story into a mvp + enhancements?

[stempler]

@thorsten-reitz I would vote for restricting it to certain "modes" as mentioned above and leave any custom/generic configuration for an improvement. For the modes we could define must-haves and leave others for improvements as well.