The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Schemas can only restrict the order they may appear in. (order=any or whatever means no restriction, but it still keeps the subelements in document order)
I'm pretty darned confident of this, but do correct me if I'm wrong. The *only* exception i could think of would be something that allows reordering by schema "key" field, or perhaps "id" field but i've never seen an implementation that does this, and I think it's not cool to do.
So I'd put rent money on this assertion. I don't rent, but still.
I would try to justify my claim but I just don't have enough spare time to point out all the wrongs with it. Let's just say it's very biased and the examples are not practical and have been cherry picked to fit the agenda.
For example, at one point it uses XPath to show how easy it is to get elements with a certain attribute using XML, but then suggests you need to write a multiple line for-loop to deal with the JSON equivalent...
Personally I don't have a problem with either, pick what best suits the requirements, as is true with most things.
I think it got that reputation on account of being the first widely adopted extensible textual structured data format online. It was really the idea of such a format that was a fix all rather than Xml itself, if anything. just my $0.02
RPCs are generally for people who couldn't be bothered to write state machines. Which means that they're usually execrable. They're why a little spinning wheel appears on the screen and you can sit there and stare at it until the cows come home or it has the courtesy to time out. Utter dross.
What you're missing is the internet. This is a client server scenario. At some point the client needs to fetch data from the server.
It has nothing to do with async and everything to do with the basic problem of communicating across a network boundary.
I feel like we're talking about two totally different things. Remote procedure calls - a way to call a method across a network boundary.
Maybe we are talking about two different things. To me, an RPC (so named because it behaves as if you called a procedure that returned a result) is a blocking send. Synchronous messaging. The send function waits for the result to arrive, causing the thread to be scheduled out.
The usual meaning of RPC is that the client blocks until the server responds. Getting back a token that is later used to retrieve the result doesn't make it look like a regular procedure call. But it's a much better way to do it.