On Wednesday, August 29, 2018 at 11:24:00 AM UTC+2, gunter zeilinger wrote:
> I stumbled over following incompatibilities between DICOM binary, XML and JSON encoding capabilities:
>
> 1. The value space of IEEE 754:1985 16-bit and 32-bit Floating Point Numbers - and therefore DICOM attributes with Value Representation (VR) FL and FD - includes codes for NaN, +ve Infinity and -ve Infinity, which representation is only supported by XML datatypes xs:float and xs:double [https://www.w3.org/TR/xmlschema-2/#float]:
>
> > The special values positive and negative infinity and not-a-number have lexical representations INF, -INF and NaN, respectively.
>
> , but not by a JSON Number [https://tools.ietf.org/html/rfc7159.html#page-7]
>
> > Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted.
>
> 2. In the binary encoding individual values inside multiple values can only be absent for attributes with a string type VR, but not with a binary VR.. E.g. you can encode an attribute with VR IS with an empty first and a non-empty second value by "\2", but you can't encode an attribute with VR SS,SL,US,UL with an empty first value. In XML and JSON individual values inside multiple values can be absent or set to null for attributes with any VR, E..g.
>
> <DicomAttribute tag=ggggeeee vr="US">
> <Value number="2">2</Value>
> </DicomAttribute>
>
> ggggeeee : { "vr": "US" , "Value": [ null, 2 ] }
>
> 3. The DICOM binary encoding does not constrain values of attributes with VR IS and DS to string representations of integer of float numbers, but the JSON representation does.
>
> 4. The DICOM binary encoding does not constrain values of attributes with VR PN to valid Person Names (up to 3 groups of up to 5 components), but the XML representation - and concerning the number of groups also the JSON representation - does.
>
> Issue 3 and 4 are rather issues of individual implementations and not of the specification. But it may help improving interoperability if the specification would recommend how a gateway implementation - which is itself not responsible for the incorrect values in received data sets - shall handle them.
>
> Issue 2 may be "solved" by constraining the absence of values in multi-values in the XML and JSON representation also to attributes with a string type VR.
>
> Issue 1 may be solved by explicitly permitting bare (=without quotes) "Infinity", "-Infinity", "NaN" as values for JSON numbers - contrary to RFC 7159 but in accordance with many JSON implementations (https://stackoverflow.com/questions/21896792/force-json-stringify-to-emit-nan-infinity-or-js-json-lib-that-does-so ).
>
> Any thoughts?

There is also the famous trick of changing the VR back to UN in which case you can safely send base64...