I mean, sure, but if you're creating an XML API, you've almost certainly defined the schema. If I take JSON like

    [
      { "fruit": "banana" },
      { "color": "yellow" },
      [ 1 ]
    ]

...and turn it into XML like...

    <document>
      <fruit>banana</fruit>
      <color>yellow</color>
      <ids>
        <id>1</id>
      </ids>
    </document>

It's going to be fairly clear what's going on.

I'd generally prefer to work with JSON, too. But the silver lining of XML is that you can define virtually any schema you want, and there are times that's conceivably going to be clearer or even more concise than the equivalent JSON.

If you don't know that "results" is an array... how do you handle the uncontroversial case of getting back an array of two results?

I know that but the PHP deserializer doesn’t know and gives me back an object instead of an array of one. If it’s two it detects an array.

But it's always a single object. If it has two parallel nodes at the document root, it isn't valid XML.

So an array of two results looks like this:

    <results>
      <result></result>
      <result></result>
    </results>

and PHP automatically treats results as a two-element array, but for the one-element array

    <results>
      <result></result>
    </results>

you just get a parse error?

Not a parse error but a single “result” object, not an array of length 1. With two elements it recognizes an array.

If you can parse

    <results>
      <result></result>
    </results>

and you end up with a single "result" object, you must have identified "results" as being an array of one element so that you could discard it. (You didn't get a single "results" object.)

That's not a problem in what XML is able to model, it's a problem with you throwing the information you got away and then pretending you didn't receive it.

On the other hand, if you meant that you get a single "results" object, then you're saying that your code is written to require invalid XML and fall down when valid XML is provided. Again, that sounds more like a problem with your code than with the modeling capabilities of XML. There's an argument to be made for accepting invalid input; rejecting valid input is ridiculous.

You do understand that php and quite a few other languages provide pre-built serialization and de-serialization from XML, right? The OP was talking about the out of box behaviour for those. Your answer seems to predicate on having written a custom deserializer.

My answer is predicated on the idea that you should be using a deserializer that doesn't rely on receiving invalid input, regardless of whether that deserializer comes from a standard library.