Skip to content

Ideas on derivation #235

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
enikao wants to merge 9 commits into
base: main
Choose a base branch
from
Draft

Ideas on derivation #235

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
0c7902c
first sketch on derived models
enikao Feb 4, 2024
1b02ab2
updated with latest decisions
enikao Feb 11, 2024
f391c34
added error cases
enikao Feb 11, 2024
10d53c7
added more error cases
enikao Feb 11, 2024
db531f3
Added some question to the derivation document.
joswarmer Mar 11, 2024
688e692
Definitions and questions about Processors and Derived Models
joswarmer Apr 2, 2024
0db9eb8
Typos
joswarmer Apr 2, 2024
433a2a5
completeness scenario as sequence diagram
enikao May 7, 2024
3d5a879
added inboxes
enikao May 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions derived/derivation.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,11 @@ IDerived "0..*" -> "1..*" Node: base
Each derived node references one or more base nodes.
Any (base) node can have none or more derived nodes.

[horizontal,labelwidth=12]
QUESTION:: Should a derived node also be able to refer to features inside a node? Or do we leave that for specific classes implementing `IDerived`?
Copy link
Contributor Author

@enikao enikao Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the example below, the PropertyViolation points to a specific feature.

Assume the following concepts:

concept Person [id=P, key=pers]
  property firstName: string [id=PF, key=firstN]
  property lastName: string [id=PL, key=lastN]

concept EmptyNameViolation implements IDerived, IViolation [id=ENV, key=emptyNameV]
  property message: string [id=ENVM, key=msg]
  reference property: Property [id=ENVP, key=prop]

Original model contains instance:

Person A [id=2]
  firstName = "John"
  lastName = ""

Validation derived model contains instance:

EmptyNameViolation B [id=5]
  message = "lastName is empty!"
  base = --> A[id=2]
  property = --> lastName[id=PL]

QUESTION:: The assumption is that derived nodes can have children that are not derived nodes.
Copy link
Contributor Author

@enikao enikao Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Derived nodes can have any kind of features, including children that might or might not implement IDerived.

Of course children could also be derived nodes.

== Client use cases:
* "Which validation issues have been found on this partition?"

Expand Down Expand Up @@ -134,6 +139,9 @@ We need to omit the parameter if we don't want to limit the depth.
==== Result
{chunk} containing all derived nodes according to `nodeIds`, `languages`, and `depthLimit` parameters.

[horizontal,labelwidth=12]
QUESTION:: The `depth:Limit` describes the depth of the retrieved nodes (derived nodes may be full trees), the next line suggests that `depthLimit` applies to the node id's sent. Needs clarification.
Copy link
Contributor Author

@enikao enikao Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is:

  1. We select the same original nodes as with Bulk API retrieve
  2. For all these nodes, we find their derivations (if available)
  3. For all derivations, we return the derivations and all descendants thereof with infinite depth.
    The assumption is that derived nodes only contain other nodes that are part of the derived information.


First, we find all _base_ nodes according to `nodeIds` and `depthLimit` parameter (see <<{bulk}.adoc#retrieve, Bulk retrieve>>).
Then, we find all _derivations_ according to `languages`.
The result contains all derivations and all their descendants.
Expand All @@ -143,6 +151,8 @@ Does NOT include the definition of <<{serialization}.adoc#UsedLanguage, UsedLang


== Possible derivation backends
[horizontal,labelwidth=12]
QUESTION:: The repository that is referred to is this always the repository where the opriginal model is stored, or could oit be a different (i.e. derivation processor specific) repository?
Copy link
Contributor Author

@enikao enikao Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formally the derivation backend implementation is independent of the repository implementation, i.e. they don't need to be the same "service". (In practice in makes a lot of sense to couple them, though.)

Derived models are part of the same repository as the original model in the sense that they share one id-space, and can refer to each other.


[[permanent-repo, permanently stored in repository]]
Permanently stored in repository::
Expand Down Expand Up @@ -270,6 +280,9 @@ package M3 {
}
----

[horizontal,labelwidth=12]
QUESTION:: Should the `PropertyValidation` also point to the Property instance in the M2 model being validated, and not just to the node that contains the property?
Copy link
Contributor Author

@enikao enikao Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See remark above.


.Available backends
* <<temp-repo>> Domain validator providing `ValidationLang` _ava_
* <<internal>> Typesystem calculator providing `TypeLang` _ava_
Expand Down