Stream: implementers
Topic: Namespaced Logical Strucuture Definitions
Chris Moesel (Oct 06 2016 at 18:17):
StructureDefinition now allows for the "logical" kind in order to support arbitrary logical models defined using StructureDefinition.
What is the best way to namespace a logical model in a StructureDefinition (in order to prevent naming collisions)? Is it valid to put the namespace into the "id" itself (e.g., "org.example.Foo")? I've done this, but one result is that in the snapshot/differential, all the paths must be prefixed by the "id", so now you end up with paths like "org.example.Foo.bar". Since dot (".") is used to separate path elements, is it a problem to have "." in the "id", which puts it in the "base" part of the path? Or might using "." in the id cause problems for code generators?
I could also just make the "id" be "Foo" and use "url" (and possibly an alternate "identifier") to specify a more fully qualified name, but that would allow this "Foo" to clash with any other "Foo" logical models in the same system (even if they have different namespaces).
Is there a recommended approach?
Grahame Grieve (Oct 06 2016 at 18:44):
we would expect that you'd just put the namespace in the URL
Chris Moesel (Oct 06 2016 at 19:19):
If a system wanted to use FHIR infrastructure to support a RESTful API for the logical models, then wouldn't it define the endpoints as http://path/to/base/${id} -- in which case, models with the same id would clash? Or are instances of logical models never expected to be exchanged over the wire (despite the fact that StructureDefinition has serialization/deserialization semantics built in)?
Grahame Grieve (Oct 06 2016 at 19:23):
it's useful that there is serialization built in, and I've used that in several places (Logical model for CDA, for instance). But there's no support for using Logical Models with the RESTful API
Chris Moesel (Oct 06 2016 at 19:24):
OK. Thanks for your help, Grahame!
Grahame Grieve (Oct 06 2016 at 19:24):
there's an ongoing discussion about that, but it's not going very far very fast. however in all the discussions we've had, we've assumed that there will be additional control over the naming if you want to use it in this context
Grahame Grieve (Oct 06 2016 at 19:25):
http://wiki.hl7.org/index.php?title=FHIR_Custom_Resources
Chris Moesel (Oct 06 2016 at 19:25):
Alright. But in your view, trying to put a namespace in the "id" (dot-separated) is probably a bad idea -- and we should avoid it?
Grahame Grieve (Oct 06 2016 at 19:26):
yes, indeed, it is problematic
Chris Moesel (Oct 06 2016 at 19:28):
OK. Just reading through that wiki link you sent, I found this:
In addition, all custom resource names will include at least one character '-' or '.', while official resources defined in the FHIR specification will never include the characters '-' or '.' in their name.
and this:
Applicants may apply for a custom name, or for a prefix that they can use with any custom resource that they define.
Chris Moesel (Oct 06 2016 at 19:29):
That kind of sounds like the approach I was going toward. But it sounds like that's still very much in flux -- so it would be premature to adopt it or to assume it is safe.
Grahame Grieve (Oct 06 2016 at 19:29):
indeed, you've identified something that would be problematic if we ever tried to operationalise that document.
Chris Moesel (Oct 06 2016 at 19:30):
OK. Thanks again. This has really been helpful. We'll plan to use a simple name and use the url to indicate the namespace.
Grahame Grieve (Oct 06 2016 at 19:30):
yes, it was something I was pushing about a year ago, but it was extremely controversial for some members of the community, and no one was sufficiently interested in actually making use of it in practice
Chris Moesel (Oct 06 2016 at 19:31):
Ha. OK. Well, I'm glad that just the general concept of logical models made it through. That will be of use to us, even without a well-defined strategy for exchange.
Stephen Royce (Oct 07 2016 at 01:22):
We a;ready doing this in Aus and we do want our logical models to be available via the ReSTful API so we make sure we avoid collisions by using different model names, e.g. "AdverseReaction" instead of "AllergyIntolerance", and using a prefix, in our case "dh-".
Grahame Grieve (Oct 07 2016 at 01:28):
what do you mean 'available in the RESTful API'?
Stephen Royce (Oct 07 2016 at 03:06):
I mean that we will stand up a FHIR server at which you can query [base]/StructureDefinition/dh-AdverseReaction and get the StructureDefinition resource for the logical adverse reaction model in the same way you would get the StructureDefinition resource for AllergyIntolerance at [base]/StructureDefinition/AllergyIntolerance.
Grahame Grieve (Oct 07 2016 at 03:11):
that's a quite different thing that what Chris meant
Stephen Royce (Oct 07 2016 at 03:36):
How is that different from "If a system wanted to use FHIR infrastructure to support a RESTful API for the logical models, then wouldn't it define the endpoints as http://path/to/base/${id} ..."?
Grahame Grieve (Oct 07 2016 at 05:48):
the difference between GET [base]/StructureDefinition/dh-AdverseReaction and Get [base]/dh-AdverseReaction/[id]
Chris Moesel (Oct 07 2016 at 20:28):
Right-- I was talking about exchanging data that adhered to the logical definition, whereas it sounds like Stephen is talking about downloading the definition itself. That said, the same risk of naming collisions exists in both cases.
Grahame Grieve (Oct 07 2016 at 20:32):
I don't see why there's a risk in the second case
Chris Moesel (Oct 07 2016 at 20:59):
With the "dh-" prefix, the risk is certainly smaller. But, in general, here's the risk in each case (as I see it):
GET [base]/StructureDefinition/Foo: if the system wanted to support another logical model called "Foo", but with a different namespace, then this call wouldn't know which "Foo" StructureDefinition to return.Get [base]/Foo/[id]: while the id would keep the full URL from clashing, the endpoint[base]/Foo/is ambiguous in regards to what type of thing it talks about. Even if the backend could support resolving to the right thing, it would be terrible from a RESTful point-of-view.
Grahame Grieve (Oct 07 2016 at 21:44):
in the first case, there can only be one Foo. No ambiguity there. I'm not going to think about the second
Last updated: Apr 12 2022 at 19:14 UTC
