Stream: fhir/infrastructure-wg
Topic: instantiates[x]
Grahame Grieve (May 28 2019 at 23:45):
The Event pattern (http://build.fhir.org/event.html) has this:
Grahame Grieve (May 28 2019 at 23:45):
Grahame Grieve (May 28 2019 at 23:47):
this pattern is not filling me with pleasure at all. We could have this instead:
instantiates[x] : 0..* canonical | uri except that we have no way to do true type choice in an array in JSON. but we could just declare that it means two separate arrays with types...
Grahame Grieve (May 28 2019 at 23:48):
that would clean up the definitions without changing the problem space at all
Grahame Grieve (May 28 2019 at 23:49):
Though note that I'm not sure that the whole choice between canonical and uri is actually very useful. It's a uri either way, we're just making rules about what the URI can refer to - I feel as though doing that by type is a pretty ham-fisted way to do it
Grahame Grieve (May 28 2019 at 23:50):
this pattern, btw, appears in lots of resources. It's not really the pattern that I can about....
Lloyd McKenzie (May 29 2019 at 01:58):
Canonical drives code that URI doesn't. Text instructions don't. Yes it's ugly, but it's computable. How are you going to enforce allowed targets, profiles, bundling, etc. if you make it a url across the board?
Grahame Grieve (May 29 2019 at 01:59):
well, it's the target that matters, right?
Lloyd McKenzie (May 29 2019 at 02:02):
Target(s) and bundled /contained/referenced both matter.
Grahame Grieve (May 29 2019 at 02:03):
sure. so it seems to me that we should be able to deal with this pattern - same literal syntax, but different consequences - more cleanly than we do now
Lloyd McKenzie (May 29 2019 at 02:06):
Interested to hear proposals...
Grahame Grieve (May 29 2019 at 02:36):
so it's a common pattern beyond just this place: a url that might be a definitional resource, or might be some pdf or published paper. And sometimes we that it must be constrained to a computable definition in the spec itself, and sometimes we want to say that in a profile
Lloyd McKenzie (May 29 2019 at 02:43):
Agree. But how do we address it? Introduce a common parent type?
Josh Mandel (May 29 2019 at 20:41):
I might rather see "normal" references where a system can recognize some values as "special"/canonical.
Josh Mandel (May 29 2019 at 20:41):
(This has come up in our Argonaut discussion of Topics for a subscription.)
Grahame Grieve (May 29 2019 at 20:42):
I don't really know what this means in practice:
I might rather see "normal" references where a system can recognize some values as "special"/canonical.
Josh Mandel (May 29 2019 at 20:43):
Oh, sorry -- I just mean using instantiates as a reference :)
Josh Mandel (May 29 2019 at 20:43):
(Or, barring that, settling on instantiatesUri)
Grahame Grieve (May 29 2019 at 20:43):
I assumed that, but still didn't really understand your intent
Josh Mandel (May 29 2019 at 20:46):
To avoid modeling references to content (whether canonical or not, and whether "constrained to URIs" or not) 3 distinct ways.
Brian Postlethwaite (Jun 03 2019 at 11:23):
A simple URI doesn't invoke all that fancy behavior where business versioning applies (with the |3.0, or just latest) that Canonical does - which I'm still a little fuzzy on.
Ewout Kramer (Jun 04 2019 at 11:39):
this pattern is not filling me with pleasure at all. We could have this instead:
instantiates[x] : 0..* canonical | uriexcept that we have no way to do true type choice in an array in JSON. but we could just declare that it means two separate arrays with types...
Before we pull things apart - is there a real pain we're trying to fix, so we know we end up in a better spot? It seems that what we have now at least works without introducing new formalisms?
Grahame Grieve (Jun 04 2019 at 12:48):
It does but it confuses implementers plenty. I’m seeking an approach that is less confusing for implementers
Lloyd McKenzie (Jun 04 2019 at 15:00):
The only solution I can think of is a common parent concrete type. Can you think of others @Grahame Grieve ?
Ewout Kramer (Jun 05 2019 at 09:41):
We have a common parent concrete type, uri is the parent of canonical. But we don't allow substitution - constraining uri to canonical in a profile would meet the requirements, but a big change in our methodology. Also, you could not express the actual type in the instance (in json) when the element repeats. Creating a new type that contains both representations has deep consequences for resolution (and indexing in servers), and would be a breaking change if we'd have to introduce it in normative resources.
Ewout Kramer (Jun 05 2019 at 09:42):
Can't we solve this visually, but not methodologically? I.e. if its confusing for developers is the problem in how we represent it in the UML/Structure in the spec?
Ewout Kramer (Jun 05 2019 at 09:43):
It's actually already quite distinct (choices are nested, Grahame's example above are siblings).
Ewout Kramer (Jun 05 2019 at 09:45):
"but we could just declare that it means two separate arrays with types..."
This suggests we want to actually MAKE it look like a choice - it's just that our limit of the json representation forces us into two seperate elements, is that correct?
Ewout Kramer (Jun 05 2019 at 09:45):
Just trying to figure out what the confusion is about and what we want to achieve....
Grahame Grieve (Sep 06 2019 at 21:18):
back to this... it's unsolved business, and I still feel this is a one area where we can improve
Grahame Grieve (Sep 06 2019 at 21:18):
it's not like the actual order of things matters here?
Lloyd McKenzie (Sep 06 2019 at 21:45):
Order isn't an issue. It's the difference in type and behavior.
Grahame Grieve (Sep 06 2019 at 21:48):
there's no difference in type, really. It's the behavior that matters
Lloyd McKenzie (Sep 06 2019 at 21:49):
Right now, the behavior is tied to the type. And there needs to be a way to distinguish what the expected behavior is.
Grahame Grieve (Sep 06 2019 at 21:52):
yes type is a proxy here. I'm wondering if there's a better way. What behaviors do we really care about?
- it refers to something
- it refers to something that's actually computable (e.g. a resource)
- it refers to a particular kind of resource
Grahame Grieve (Sep 06 2019 at 21:53):
and we care for a receiving system to know whether it should before it follows the link?
Lloyd McKenzie (Sep 06 2019 at 23:17):
The canonical can be parsed to extract a base and a version and the retrieval can occur by doing a query of known registries (and local system) using url & version as search parameters rather than resolving - and that search strategy should happen before trying to resolve the URL
Lloyd McKenzie (Sep 06 2019 at 23:18):
On the other hand, the URI isn't expected to resolve to anything computable and if it does resolve, it only does so by hitting the URI
Last updated: Apr 12 2022 at 19:14 UTC
