What does `"path": "Extension"` mean in an extensions element - hl7-fhir

In a StructureDefinition like
"entry": [
{
"fullUrl": "http://hl7.org/fhir/StructureDefinition/condition-dueTo",
"resource": {
...
"base": "http://hl7.org/fhir/StructureDefinition/Extension",
"differential": {
"element": [
{
"path": "Extension",
, what is it "path": "Extension" points to?
I'm working on generating client code that also can handle extensions, and I'm struggling to figure out how this path should be interpreted.
As far as I understand it, the next element
{
"path": "Extension.extension",
"name": "code",
constraints the extension property of the current extensions base (Extension).
Please correct me if this is wrong.
If Extension would point to the base extension, then how is
"min": 0,
"max": "*",
to interpret.
So the main question again. How to interpret this path in an extension:
"path": "Extension",

StructureDefinitions define hierarchical structures with a flat list of elements in the snapshot view. The hierarchy is expressed via the hierarchy of .-separated node names in "path".
Path in differential points to a path in the snapshot. It identifies the "node" within the structural hierarchy of the resource, data type, extension, etc. In this case, "Extension" has no periods in it, so it refers to the root element of the extension. If it was Extension.extension or Extension.url or Extension.valueCodeableConcept.coding.code or something like that, it would refer to a deeper element within the hierarchy of the structure.

Related

Sass doc is giving me duplicate results

My output tree is showing duplicates and I can't figure out why. This is prototype angular project with this file tree. I can't figure out why.
src
app
components
scss
styles.scss
Here's my out put tree
My sassdoc.json config
{
"basePath": "https://mjhandy.github.io/AngularBoilerPlate/docs/sass/",
"package": {
"title": "Angular Boilerplate",
"name": "ngBoilerplate",
"description": "My boilerplate for basic, resuable, Angular components"
},
"dest": "./docs/sassdoc",
"excliude": [
"./src/scss/_mixins.scss"
],
"groups" : {
"structure" : "Structure",
"component" : "Component",
"helpers" : "Helpers",
"global" : "Global Items",
"mixins" : "Mixins"
},
"options": {
"display": {
"watermark": false
}
}
}
My run commands :
sassdoc ./src/**/* -c sassdoc.json
I ran into the same result with the following command within my package.json scripts
sassdoc 'src/assets/styles/sass/**'
According to the official sassdoc documentation they are using this library to parse glob patterns.
The ** notation matches the directory itself, its containing files and its subdirectories.
But the root directory name is suffice for the sassdoc, it will iterate over its tree structure if any.
sassdoc 'src/assets/styles/sass/*'
# or simply
sassdoc 'src/assets/styles/sass'

Add an allowed tag name to the HTML language mode

I'm using Foundation for Emails, which has a few unique tag names that are later parsed. Specifically, VSCode doesn't seem to like <spacer>:
How do I add <spacer> as an known/allowed tag so it's not redded out by VSCode?
You can use HTML custom data. Create a JSON file, e.g. spacer.html-data.json:
{
"version": 1.1,
"tags": [
{
"name": "spacer",
"description": "Foundation spacer",
"attributes": [
{
"name": "size",
"description": "Spacer size"
}
]
}
]
}
And include it in your VS Code JSON configuration:
"html.customData": [
"./spacer.html-data.json"
]
Note that this has to be a path relative to your opened folder/workspace.
EDIT: Oh, I just realized that this does not prevent the red colouring in this special case. Probably this is becaue spacer used to be a valid HTML tag but is deprecated now. I have no idea how to change this behaviour in VS code.

jmeter json path Conditional Extraction at peer level

I'm using jmeter v2.13 and jp#gc - JSON Path Extractor.
Here is my JSON sample:
{
"views": [{
"id": 9701,
"name": " EBS: EAS: IDC (EAS MBT IDC)",
"canEdit": true,
"sprintSupportEnabled": true,
"filter": {
"id": 55464,
"name": "Filter for EBS: EAS: IDC & oBill Boar",
"query": "project = \"EBS: EAS: IDC\"",
"owner": {},
"canEdit": false,
"isOrderedByRank": true,
"permissionEntries": [{
"values": [{
"type": "Shared with the public",
"name": ""
}]
}]
},
"boardAdmins": {}
},
{}
]
}
Is it possible to extract views[x].id where there exists an entry views[x].filter.permissionEntries[*].values[*].type that equals Shared with the public?
How would I do it?
Thanks
JSON Query would look like this (I admit I didn't try it in JMeter)
$.views[?(#.filter[?(#.permissionEntries[?(#.values[?(#.type == "Shared with the public")])])])].id
Explanation:
We expect under root ($) to have views and for it to have property id. The rest (in []) are conditions to select only views items based on predefined condition. Hence $.views[conditions].id
Conditions in this case are coming one within the other, but main parts are:
We define condition as a filter ?(...)
We ask filter to look under current item (#) for a specific child item (.child), child may have its own conditions ([...]). Hence #.child[conditions]. That way we move through filter, permissionEntries, values
Finally we get to field values and filter it for a child type field with particular value Shared with the public. Hence #.type == "Shared with the public"
As you see it's not very intuitive, and JSON path is a bit limited. If this is a repetitive issue, and your JSON is even more complicated, you ay consider investing into a scriptable pre-processor (similar to the one explained here.

What is `_code` in `profile-types.json`

for example snapshot/element[2] contains
"type": [
{
"fhir_comments": [
"Note: primitive values do not have an assigned type\r\n e.g. this is compiler magic\r\n XML and JSON types provided by extension"
],
"_code": {
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-json-type",
"valueString": "string"
},
{
"url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-xml-type",
"valueString": "xs:string"
}
]
}
}
]
As far as I know there is no property _code defined for StructureDefinition
What's the correct way to treat and interpret this property?
This is the "code" element. _code is used to convey complex children on primitive data types (i.e. the id element or extensions or modifier extensions). This is defined in the specification here. The representation is done this way so you can reference primitive elements by just saying something like Patient.birthDate or Patient.gender instead of Patient.birthDate.value or Patient.gender.value. In order to allow that, we needed to provide a convention for accessing extensions and other elements which are rare, but can still be present on 'primitive' data types.

What's the correct way to present paged resources with HAL?

This sounds like a rookie question, but I'm wondering what's the best way to present paged resources with HAL format? Right now I'm using Spring HATEOAS API to convert Page object into resource PagedResourcesAssembler#toResource(Page<T>, ResourceAssembler<T,R>). This results in the following output:
{
"_links": {
"self": {
"href": "http://example.org/api/user?page=3"
},
…
}
"count": 3,
"total": 498,
"_embedded": {
"users": [
{
"_links": {
"self": {
"href": "http://example.org/api/user/mwop"
}
},
"id": "mwop",
"name": "Matthew Weier O'Phinney"
}
]
}
}
Everything works fine but the only problem is the collection being returned is under _embedded field and has the class name, so the client has to know this class name as well right? Would it be better to just return the collection under content like non-HAL format? If yes how should I achieve it using Spring HATEOAS?
That's not a problem, that's the way _embedded is defined in the HAL specification.
users is not a class, it's a link relation that will allow clients to actually find the collection it was asking for in the first place (e.g. using a JSONPath expression). That's not something coming out of the blue at all but usually is the same link relation, the client used to find that resource in the first place.
Assume an API root exposing this document:
{
"_links": {
"users": {
"href": "…"
},
…
}
}
Seeing that, the client would have to know the semantics of users to find the link it wants to follow. In your case users is basically pointing to a collection resource that supports pagination.
So if the client follows the link named users, it can then find the actual content it's looking for under _embedded.users in the HAL response by combining knowledge about the media type (HAL, _embedded) and the service's application-level semantics (users).

Resources