Spoken like a true maker. The thing works, where’s the fun in that? (grin)

I knew that website had self contained node.js binaries and I tried unzipping with with the latest release of 7zip and out would come empty files. So I just assumed it was just a practical joke or something. Didn’t even think about trying 7zip beta.
Have a good weekend.

I once came across the opinion that what makes it so hard is the same thing that made it so successful: it started out as a conglomeration of very different protocols used by quite a few giant vendors. The only way to get such mess under the umbrella of a single standard was for the standard to *allow* many diverged implementation choices, at various junctions.

While this thought does have some ground (e.g., in transfer syntax negotiation), I don’t think it’s the *main* difficulty. I now think it is just very, very, poorly written. For one, it is packed with legally-phrased introductions, that serve no purpose other than to wear out the reader. Random example:
“In order to serve as an SCP of the Query/Retrieve Service Class, a DICOM AE possesses information about the Attributes of a number of stored composite object SOP Instances. This information is organized into a well defined Query/Retrieve Information Model. The Query/Retrieve Information Model shall be a standard Query/Retrieve Information Model, as defined in this Annex of the DICOM Standard.
Queries and Retrievals are implemented against well defined Information Models. A specific SOP Class of the Query/Retrieve Service Class consists of an Information Model Definition and DIMSE-C Service Group. In this Service Class, the Information Model plays a role similar to an Information Object Definition (IOD) of most other DICOM Service Classes… ” etc. etc. etc. etc.

For two, the standard designers apparently had an extreme affection for classifying stuff. Whenever the standard acknowledges 4 types of widgets, They are grouped into 2 ‘widget object entity definitions’, each definition containing exactly two widgets, and separately characterized by 2 ‘information widget model factors’. These two atrocities are tediously defined over 1.5 pages, and add up to a neat table like -
Widget | WODT | IWMF
———————–
1 | 1 | B
2 | 1 | L
3 | 2 | L
4 | 2 | B*

____________
* this is in fact a different IWMF, should have really been labeled Q.

Almost nowhere in the standard, can you just find the section about the widget you desire and just read what it does. You typically need many, many pages of useless terminology to be able to read the info bit you seek. Pop quiz: can you understand the distinction between normal and composite service classes? (I sure can’t). If you do, can you see any value in this distinction?

Seems to me that the task undertaken by, say, the c++ standard designers – is far more complex, and they produced an infinitely more readable document, at about 25% of the pages. On the brighter side, this quality of a standard keeps the jobs of many a DICOM specialist tightly secured .