Skip to content
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.

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

Inheritance of Resource, DomainResource, Element and BackboneElement #26

Open
Waitak opened this issue Dec 30, 2015 · 8 comments
Open

Comments

@Waitak
Copy link

Waitak commented Dec 30, 2015

In the XML Schema Resource, DomainResource, Element and BackboneElement are parent types of most of the data and resource types. In particular, they include fields like Language and Extension. These seem to be absent from the various classes, or am I missing something?

@cmoesel
Copy link
Contributor

cmoesel commented Jan 4, 2016

You are correct -- the current code in master does not reflect the properties of any of these base resources or elements (except for id). I recently submitted a pull request (#25) that addresses some of this by having resources properly inherit from DomainResource (and DomainResource inherits from Resource). One of my colleagues is reviewing the PR and will likely merge it soon. This will get you all of the basic goodies on resources (id, meta, extension, etc).

We don't yet have a plan, however, for support of BackboneElement and/or Element. This means that non-resource elements (e.g., primitive types) can't have ids or extensions. To be honest, it's one of those things we've been hesitant to implement because we really don't like the idea of extending primitives (it pretty much defeats the normal notion of what a primitive is). It's not needed by our main use case, and I think we've been hoping it would be voted out of the spec. ;-) That said, if it's here to stay, we probably need to think more seriously about it -- but it does make implementation much more clunky (sigh). Is this something that will prohibit you from using and/or contributing to this project?

@Waitak
Copy link
Author

Waitak commented Jan 28, 2016

Well, I make regular use of the language element, which is defined at the parent class level. I can do without the internal ID, which is the other main contribution, but language is a gotta-have for my use case.

@cmoesel
Copy link
Contributor

cmoesel commented Jan 28, 2016

Support for the base DomainResource and Resource classes was added in PR #25, which has now been merged to master. So... language shouldn't be a problem anymore. Does that resolve your main concerns?

@Waitak
Copy link
Author

Waitak commented Feb 9, 2016

That's great, thank you. What are the plans for implementing CodeSystem?

@cmoesel
Copy link
Contributor

cmoesel commented Feb 9, 2016

I'm not entirely sure what you mean by "implementing CodeSystem" -- could you provide a few more details? CodeSystem isn't a resource, but the ValueSet resource defines a CodeSystem component for defining code systems inline. Is that what you're talking about? (If so, our model supports that already).

@Waitak
Copy link
Author

Waitak commented Feb 9, 2016

CodeSystem is now a resource, actually: http://hl7-fhir.github.io/codesystem.html
The plan (since Orlando) is to move all code systems out of value sets and into their own, separate resource. It's quite a major change.

@cmoesel
Copy link
Contributor

cmoesel commented Feb 9, 2016

Oh. I see. This wasn't on my radar, as we've been focused on DSTU2. Right now, we remain focused on DSTU2, so I wouldn't expect to see support for CodeSystem until closer to DSTU3.

That said, much of our code is generated from the FHIR tool chain, so it may be possible to rebase our code generation on a later version of the FHIR sources and generate out the latest (DSTU3) resources (assuming the tool chain itself hasn't changed a lot) -- but that would require forks of our fhir and fhir-golang-generator projects -- and maintaining those forks while we continue to work on the master branches. If this is something you're truly interested in, let me know and we can throw you a few pointers.

@Waitak
Copy link
Author

Waitak commented Feb 9, 2016

I am, thank you. Might a different channel be better to chat about it? IRC? Email? Skype?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants