value attribute should be child when representation = xmlAttr

[cknaap]

In some logical models it is possible to have an element with a value attribute that is actually a child - along with other children. Example: TEL in ccda. Excerpt of the definition:

    <element id="TEL.value">
      <path value="TEL.value"/>
      <representation value="xmlAttr"/>
      <min value="0"/>
      <max value="1"/>
      <type>
        <code value="uri"/>
      </type>
    </element>
    <element id="TEL.use">
      <path value="TEL.use"/>
      <representation value="xmlAttr"/>
      <label value="Use Code"/>
      <definition value="..."/>
      <min value="0"/>
      <max value="*"/>
      <type>
        <code value="code"/>
      </type>
      <binding>...</binding>
    </element>

Example instance data: <telecom use="WP" value="tel:1(878)378-0909"/>

The problem is in the <representation value="xmlAttr">. For TEL.use this works fine in the API. But the value attribute is always read into the FhirXmlNode.Text property. That is not correct in this case, value should be a child element.

This problem manifests itself in the use of the mapping language on a TEL source element. You cannot map the TEL.value element because it is not accessible as child element.

This might be related to #1209

[cknaap]

Issue1270.zip Logical model for ccda TEL and example instance containing a TEL element.

[ewoutkramer]

This is related to #1221. The 'value' being special is pretty deeply embedded in the code - and since FhirXmlNode has no metadata (so knows nothing about representation), there's very little to do about it - except swapping out the FhirXmlNode class for another parser (e.g. we could make a LogicalXmlNode) or a configuration setting on FhirXmlNode to not treat value as special, and fill the ISourceNode.Text with either the attribute value or the XText node value.

[cknaap]

Could it be solved when typing the node, transforming it into an ITypedElement?

[mmsmits]

We will not invest in the CCDA stack in combination with ITypedElement anymore. If the need arises, we are now thinking of writing an XML Parser for CCDA to Poco's specifically.