Stream: conformance
Topic: GraphDefinition as 'open' or 'closed' definition
Eric Haas (Dec 17 2019 at 01:57):
Is there a way to say using MessageDef or GraphDef these are all the edges that are allowed? ( or conversely this is the minimum but there could be more) I could not find any and I think for messaging it might be useful to nail it down. Thoughts?
René Spronk (Dec 17 2019 at 07:31):
In my new proposal for GraphDefinition (HL7 Jira site is down at the moment) I'm silent on this, but the default thinking was 'closed'. This question was already on my list.. we could define a flag define the entire Graph to be 'open'. This could be an argument to start using Sub-graphs, because then some sub-graphs could be open whereas others could be closed. It does however add to the complexity. We'll also have to think of the Graph validation software: an open definition presumably would be harder to validate than a closed definition.
Eric Haas (Dec 17 2019 at 14:34):
but the default thinking was 'closed'.
Is this thethinking using the current GD as well? I was not aware of that and did not see it documented?
René Spronk (Dec 17 2019 at 15:27):
@Grahame Grieve ? I don't think it's stated anywhere..
Grahame Grieve (Dec 17 2019 at 19:04):
It's not closed in that sense
René Spronk (Dec 19 2019 at 08:55):
GraphDef is build on StrucDefs (those can be open or closed in nature). GraphDef allows one to define cardinalities when it comes to (inbound/outbound) references, those could be bound (closed) or unbound (open). GraphDef allows one to constrain the number of instance resources of a type, but the cardinality needs not be limited.
In other words: GraphDef allows you to create fully open graphs, full closed ones, or hybrids.
Eric Haas (Dec 21 2019 at 00:39):
Is it possible to discuss this at Sydney? I agree with what @René Spronk is saying...but when I say closed in the context of a Graph: I meant is this a complete graph overall and you can't add any more edges. By open I mean you are allowed to add more edges the the graph.
René Spronk (Dec 24 2019 at 10:40):
We'd need an attribute as part of the 'header' of GraphDefinition to ensure the definition is closed. Remember that if one of the StrucDefs referenced by the Graph is open, then the entire Graph is open. So labeling a Graph as closed effectively turns all open strucDefs into closed Strucdefs as well.
Eric Haas (Dec 24 2019 at 14:17):
Ok I get it. The profiles would have to at least allow the references that the Graph defined.
Eric Haas (Dec 24 2019 at 19:08):
... but necessarily the other way around depending on the 'aggregation' in the SDs ....
Eric Haas (Dec 24 2019 at 19:11):
My wish was for the SDs (Profiles) to be generally permissive which means:
- Define only the mandatory and must supports.
- Leave all the aggregation "open"
- don't exclude any elements
Eric Haas (Dec 24 2019 at 19:14):
Then use the Graphs to define the edges ( aggregations) obviously not crossing the line where the SD excludes a reference (which would violates my permissive approach above anyway) or limits the target or cardinality and usage ( e.g., mandatory --> mandatory)
Eric Haas (Dec 24 2019 at 19:18):
So the Graph would be in control of whether the it could be open to addtitional edges or not.
...Are we saying the same thing?
René Spronk (Dec 25 2019 at 10:36):
A GraphDef could be more restrictive than a StrucDef, so yes, ultimately GraphDef fully controls the edges.
If we assume a GraphDef G has populated attributes for min/max on the edge relationships then it represents a closed graph. There are two uses cases for openess, to go beyond such a closed graph G:
- To state that anywhere there may be additional links, of reference-types not mentioned/defined in the GraphDef. This would require a new 'header' attribute on GraphDef,
- To state that on a particular node one could have additional links, f reference-types not mentioned/defined in the GraphDef for that specific node. This use case can be solved by adding a new node for resource type "Resource" (effectively an ANY).
Note that if we were to ever introduce sub-graphs in GraphDef this will get even more complex. But let's not go there right now until we have a very good use case which requires it.
Last updated: Apr 12 2022 at 19:14 UTC
