FHIR Chat · Primitive Validation Questions · conformance

Stream: conformance

Topic: Primitive Validation Questions

Grahame Grieve (Jul 30 2019 at 01:55):

I'm reviewing the validation of primitive values by the validator. I have a couple of issues:
- are leading zeros allowed on exponents in decimals? we don't say anything about this (we don't allow leading zeros on the actual number).
- the validator says this is not valid:

  <parameter>
    <name value="paramMarkdownMissing"/>
    <valueMarkdown>
      <extension url="http://hl7.org/fhir/StructureDefinition/data-absent-reason">
        <valueCode value="unknown"/>
      </extension>
    </valueMarkdown>
  </parameter>

in fact, it gives 3 errors:

ERROR: Parameters.parameter[37]: A parameter must have one and only one of (value, resource, part) [(part.exists() and value.empty() and resource.empty()) or (part.empty() and (value.exists() xor resource.exists()))]
ERROR: Parameters.parameter[37].value.ofType(markdown): Primitive types must have a value that is not empty
ERROR: Parameters.parameter[37].value.ofType(markdown): All FHIR elements must have a @value or children [hasValue() or (children().count() > id.count())]

I think every one of those errors is wrong?

Grahame Grieve (Jul 30 2019 at 02:12):

related to the decimal question, we say:

Grahame Grieve (Jul 30 2019 at 02:13):

JSON is restricted to the precision limits documented in XML schema for xs:double and xs:decimal

Grahame Grieve (Jul 30 2019 at 02:14):

consulting the xs:decimal limits, I see:

All ·minimally conforming· processors ·must· support decimal numbers with a minimum of 18 decimal digits (i.e., with a ·totalDigits· of 18). However, ·minimally conforming· processors ·may· set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number ·must· be clearly documented.

Grahame Grieve (Jul 30 2019 at 02:14):

and for double, I see

Grahame Grieve (Jul 30 2019 at 02:15):

The basic ·value space· of double consists of the values m × 2^e, where m is an integer whose absolute value is less than 2^53, and e is an integer between -1075 and 970, inclusive

Grahame Grieve (Jul 30 2019 at 02:15):

I don't actually know how the double commentary is relevant

Grahame Grieve (Jul 30 2019 at 02:16):

the decimal constraints... are not constraints.

Grahame Grieve (Jul 30 2019 at 02:16):

so I'm not sure what we are trying to do here. (I know what we are doing: making a mess of precision limits)

Grahame Grieve (Jul 30 2019 at 02:21):

relevant prior discussion here on Zulip:

Grahame Grieve (Jul 30 2019 at 02:21):

• https://chat.fhir.org/#narrow/stream/179266-fhirpath/topic/Decimal.20.3D.20vs.20~
• https://chat.fhir.org/#narrow/stream/179266-fhirpath/topic/Fixed-precision.20decimal

Grahame Grieve (Jul 30 2019 at 06:25):

what the validator is presently doing:

• checking the syntax validity, allowing leading zeros on exponents
• noting a warning if there is more than 18 digits in the exponent / decimal, and if there's more than 4 digits in the mantissa

Grahame Grieve (Jul 30 2019 at 06:29):

And I just found a shockingly large bug in the validator :-(

Grahame Grieve (Jul 30 2019 at 06:29):

check this Java code, at the bottom of all primitive data type fixedValue checking

Grahame Grieve (Jul 30 2019 at 06:30):

  private boolean checkEquals(String v1, String v2) {
    return v1 == null ? Utilities.noString(v1) : v1.equals(v2);
  }

Grahame Grieve (Jul 30 2019 at 06:30):

big logic flaw: if the fixed value has null, it's supposed to check that the instance value is null. But it doesn't - it ignores it. It should be

Grahame Grieve (Jul 30 2019 at 06:31):

 private boolean checkEquals(String v1, String v2) {
    return v1 == null ? Utilities.noString(v2) : v1.equals(v2);
  }

Grahame Grieve (Jul 30 2019 at 06:42):

is -0 a valid decimal?

Grahame Grieve (Jul 30 2019 at 06:42):

I think it is

Last updated: Apr 12 2022 at 19:14 UTC