Yes - that's exactly correct.
Since Halloween is approaching, I'll use that analogy.
Suppose you walk up to 2 houses in your Halloween costume and ring the bell at each one.
House 1 has the treats set out on a table by type - one dish contains chocolate only, one dish contains treats with nuts, one has fruit, one has hard candy, one has bubble gum, and so on. You'd be able to introspect the table, and see which treats you'd like to take with you, and which you knew to avoid (nut allergies, not partial to chocolate, whatever).
But house 2 just hands you a black plastic bag with the treats sealed inside. You have to take whatever they give you, without any idea of what's inside. Only later can you open the bag and see what you've been given - and discard those treats you find objectionable.
Table 2 is the situation Marko has been given. PB can only see the "black bag", and can't determine the individual fields inside it. It's up to Marko to write a function that can take that content (in whatever form it's sent), convert it to a string, and parse it into its constituent bits.
Had the service been defined with strongly typed fields, PB would have been able to see the individual "bowls of treats", and know that field 1 contains chocolates, and field 2 contains bubble gum, and field 3 is a popcorn ball. PB's web service project would have generated a structure class that exactly mirrored that structure. Instead, all it can see is "Black Bag" (or "string", in Marko's case).
Hope this helps,
-Paul-