I believe that such system cannot fully process the data, as is written in that data's specification, without providing the type system that is in that specification.
The requirement for dynamic typing can either come from the language, or it can be "Greenspunned", or some combination of the two.
For instance, in that data we can construct objects, and we can write expressions which interrogate an object's type.
Thus, that is an example of input data whose processing requires dynamic typing.
I'm quite sure it's not. Statically-typed programs can recursively parse data, and they can also monadically (sequentially) parse data. The same is true of dynamically-typed programs.
If the detailed requirements describing the inputs require dynamic typing, then the statically typed program has to whip up a facsimile of that dynamic typing. It's not an implementation detail; it shows up in visible, testable system behaviors.
And then, there you are, with the possibility of errors that are not caught at your compile time.
I don’t get it. Why are you concerned with compile time?
The debate that the article is addressing is the supposed difference of capabilities between programs written with static vs dynamic types, at runtime.
The situation is not written entirely with static types if the run-time processing requires the expression of dynamic typing. That's based on some actual dynamic typing from the language, or else some ad hoc dynamic types cobbed together in the program itself.
