When resolving absolute or relative reference, we must take into account the version of the resource as specified in meta.versionId of the resource being referenced, if the reference contains a versionId. Does the same logic apply to references to contained resources? I ask because the Fhir .net API appears to contain version logic in functions for resolving absolute references with version specified (BundleExtensions.FindEntry), but does not have any version specific logic for in functions for resolving contained resources (DomainResource.FindContainedResource).
The FHIR documentation around referencing resources does not appear to talk about whether or not versioning applies when referencing contained resources.
Contained resources do not have an independent existence, and they cannot have a versionId (among other things), so also cannot be referenced with a version. See http://www.hl7.org/fhir/references.html#contained for more information.
When you need to change data to contained resources, you will need to update the source/parent resource which will then get a new version.
Related
I have projects that are developed with xml and python code mostly (Odoo modules). There is a bit of .po files for translation and csv fields for data.
I would like to enforce specific policies in xml files, for example:
No duplicate id attributes.
A specific attribute must be present if child elements contain a specific tags.
On python, I want to enforce rules like:
Look for SQL queries, and make sure that they use specific parameter methods to prevent SQL injection
Follow a specific naming convention
Some attributes are required in classes that inherit a specific class
I hope that the idea is clear.
Is there any open source solution for this? Preferably linked with github and checks on every commit!
I found a python package made specifically for this, pylint-odoo, here.
It can also be installed with pip install pylint-odoo.
An example .pylintrc config file can be found at the web OCA module, here. They also have another file named .pylintrc-mandatory.
There is even a warning for duplicate xml id attribute W7902.
I have written a custom chef inspec resource to work with a proprietary configuration format that the company I work for uses. I have put the resource in the .\myprofile\libraries folder as the documentation dictates that I should[1]. However, I want to use this resource in multiple profiles without copy/pasting the same resource or symlinking the resource (I'm developing on Windows). Is there a way I can define this resource in a single location and then reference it in multiple profiles?
[1] https://www.inspec.io/docs/reference/dsl_resource/
You can create a profile with your custom resource defined there. I would suggest some profile without any controls, or with minimum amount of controls, which all depend on your custom resource.
Then in the other profiles, where you need your custom resource you can reference your fist profile in inspec.yml:
depends:
- name: my_profile_with_custom_resource
path: ../relative/path
Inplace of path can be an url or a absolute path or git url (with branch and tags). By default all the controls and custom resources defined in my_profile_with_custom_resource will be available in the new profile.
I am looking at using Swashbuckle/Swagger to document my WebAPI solution. The developer portal would be something like https://myapi.com/, while the versioned API is https://myapi.com/v1/users.
The version part of the URL maps to a virtual directory, containing the binaries and config files for v1. When version 2 ships, we create a new virtual directory under the root, so now we have https://myapi.com/v2/users/some_new_endpoint_not_in_v1. This means that save for bugfixes, there is no need for any of the binaries of older versions to be touched, which reduces the likelihood of some developer accidentally breaking backwards compatibility for our customers.
However, I can't see how to configure Swashbuckle to look at those virtual directories to get the controllers/actions and XML comments to parse. The MultipleApiVersions configuration option seems more targetted at people who throw all their supported versions into one set of binaries (either by namespaces or controller names), and not by separating them into separate processes.
Any suggestions as to how I can bend Swashbuckle to my will? Should I just install Swashbuckle into the individual virtual directories as single API versions, so the docs becomes something like https://myapi.com/v1/swagger? My portal would then do the necessary work to expose the different API versions.
Update
I did try the latter approach, and for the documentation at least, it works OK. The problem is then that the URL for the Swagger spec then becomes https://myapi.com/v1/swagger/docs/v1, and I would rather not have that second v1 in the URL. Unfortunately Swaashbuckle at least expects the version number to be in the relative path, not in the base URL.
Having those would work:
Swagger UI at the root of your API site (nothing to do with Swashbuckle),
multiple virtual directories for your versions ("v1", "v2"...)
To achieve this:
the custom discoveryPaths array in Swagger UI javascript would look like below, with added "/spec" suffix (or whatever suits you, as SwashBuckle is not handling the c.SingleApiVersion with an empty version value):
var currentUrl = 'https://myapi.com/';
window.swashbuckleConfig = {
rootUrl: currentUrl,
discoveryPaths: arrayFrom('v1/swagger/docs/spec|v2/swagger/docs/spec'),
booleanValues: arrayFrom('true|false'),
validatorUrl: stringOrNullFrom('null'),
// other settings ommitted for brevity.
oAuth2AdditionalQueryStringParams: JSON.parse('{}')
};
Removing c.EnableSwaggerUi from your Web API sub apps
Working on a large project I just got assigned to and I am new to J2EE/Spring/Maven and the project consists of ~20 modules.
I cant seem to figure out why in a Module A, works, but can not find the resource, even if [Module B].xml has the same code as common.xml. Where are some possible locations/configurations/code I can look to figure out where the resource context is coming from?
I'm not completely sure of what you are asking but first read Spring documentation about importing resources. There it says:
All location paths are considered relative to the definition file doing the importing.
The DSTU for REST delete is simple send, DELETE [base]\[type]\[id].
However, what if the server implements version aware updates? Do I need to send a Content-Location HTTP header as well? As in:
DELETE ...\Patient\123
Content-Location: ...\Patient\123\_history\4
Or does the DELETE implicitly apply to the current version of the resource?
It certainly makes sense to indicate which version you are expecting to delete, especially since you can still update a resource to "undelete" it, so we're talking multiple versions here. However, the definition of the Content-Location header states:
The Content-Location entity-header field MAY be used to supply the
resource location for the entity enclosed in the message
and with a DELETE, we do not encode an entity. So, I wonder whether this is allowed. It's worth bringing this up for discussion on the HL7 FHIR site and/or gForge though.
As far as I know, and as you said in your question, FHIR do not imply with version-aware delete operations. In fact the DELETE operation only means that your resource will not be retrieved by SEARCH or READ operations. That said, given that your server implements a non-standard operation you could just answer to a DELETE request to a version url by deleting that specific version.
Let me say that, IMHO, alter the resource history is contrary to the philosophy that any change should be trackable. See http://www.hl7.org/implement/standards/fhir/security.html#audit