FHIR Chat · Element Definition · implementers

Stream: implementers

Topic: Element Definition

Chris Grenz (Mar 09 2016 at 21:27):

It appears that type/code can now be any type OR resource? This is a change from 1.0...can't find a gForge that references it. Can anyone shed some light? My question is: Should the root element of all the resources SDs be of type "DomainResource" (since that's not a type) - it would seem that a base of DomainResource would suffice?

Grahame Grieve (Mar 09 2016 at 21:28):

ElementDefinition.type.code can be a resource or a type, yes

Chris Grenz (Mar 09 2016 at 21:28):

Why the change?

Chris Grenz (Mar 09 2016 at 21:28):

It was type only in 1.0....although DomainResource was used...

Grahame Grieve (Mar 09 2016 at 21:28):

it snuck by us, I don't think there was a formal gForge proposal; we just accepted that elsewhere and had to correct ElementDefinition for that

Grahame Grieve (Mar 09 2016 at 21:29):

DomainResource is a type

Chris Grenz (Mar 09 2016 at 21:29):

So now DomainResource is both the type AND the base....

Chris Grenz (Mar 09 2016 at 21:29):

not according to the DomainResource SD....

Grahame Grieve (Mar 09 2016 at 21:32):

hm. I'll have to investigate, but can't right now

James Agnew (Apr 02 2016 at 16:05):

Question about StructureDefinition as it works now. In the profile for Questionnaire we have the following:

          <element>
            <path value="Questionnaire.item.item"/>
            <short value="Nested questionnaire items"/>
            <contentReference value="#item"/>
          </element>

What does #item refer to? The Java RI validator is looking for an element with id="item" and this doesn't exist. Is this an issue with the profile, or with the validator?

Grahame Grieve (Apr 02 2016 at 20:36):

Issue with the profile. It should exist

Lloyd McKenzie (Apr 02 2016 at 20:54):

Is this an authorship issue or a tooling issue?

Grahame Grieve (Apr 02 2016 at 21:06):

Tooling

James Agnew (Apr 03 2016 at 12:54):

tracker item filed to keep track of this.

Chris Grenz (May 25 2016 at 14:13):

Discussing GF#9843 - there are some remaining issues:

• what to do with name GF#10068 - do we a) keep it, specifying a dot notation, b) keep it as is and only allow name for new slices, or c) just get rid of it entirely. The first or second options are the least disruptive, the third least redundant.
• the id type disallows things that are valid in name. Need to either a) widen the definition of id or b) use a different type for element.id. Must at least allow "value[x]".

Ewout Kramer (May 26 2016 at 14:37):

So, I think we agreed that we should keep the name opaque, so no special meaning given to <name>. I wouldn't mind doing b), as longs as it's valid as an anchor in a URL.

Chris Grenz (May 26 2016 at 14:38):

Opened GF#10079 for the data type change to element.id to allow for valid paths.

Chris Grenz (May 26 2016 at 14:40):

So elementdefinition.name would only be allowed at the root of a new slice. Its type would be AnchorToken.

Chris Grenz (May 26 2016 at 14:40):

Is that in line with your comment @Ewout Kramer ?

Last updated: Apr 12 2022 at 19:14 UTC