You know what grinds my gears about using XSD for message definitions? Namespaces. Namespaces are a good idea and were done well in XML, as far as I can see, but with XSD you run into this [problem][1]:

Namespaces are used to qualify tags and attributes in XML elements. But they're also used by XSD to qualify the names of types defined in the schema. A sequence element's type is indicated by the value of its "type" attribute. The attribute value is a string that is the namespace-qualified name of the type.

So, if you want to change the alias of an XML namespace in an XSD schema, you can't just use your XML library's facilities for namespace management. You also have to go find the "type" attributes (but not all of the "type" attributes), parse their values, and do the corresponding alias change in the type name.

Don't use a string for a thing that is not a string! I guess in XML attributes you have no choice. XAML improved on the situation a bit.

[1]: https://github.com/dgoffredo/stag/tree/master/src/stag/xsd-u...

My condolences. Any open standard runs the risk of this happening. It's not a problem I think we'll ever solve.

In principle, if you make your standard extensible enough, people should stop sneaking data into comments or strings.

... What makes the GP's problem so much more amusing. XML was the last place I'd expect to see it.

That's assuming they know how to use it properly.

Rest has this same issue.

I've seen this when trying to integrate with 3rd party apis.

Status Code 200 Body: Sorry bro, no data.

Even then, this is subject to debate. Should a 404 only be used when the endpoint doesn't exist ? When we have no data to return, etc.

i think that default REST is a bit problematic as it conflates transport protocol level errors with application logic ones.

At least unless you use application/problem+json or application/problem+xml MIME types but those are still just in draft stage

https://datatracker.ietf.org/doc/html/rfc9457#name-the-probl...