One obvious problem is that the semantics of a DSL arent extendable in that DSL, making it highly brittle. So, eg., with parsing, as soon as you need bespoke syntax-error handling, etc. etc. you're leaving the world of any DSL you can create. Since "bespoke" here will, ultimately mean, a semantic specialisation that no generic DSL will support.
At the point where your DSL enables these abitary specialisations, it is just the host language.
An xml/json schema is for validating a serialization format; a DSL-in-ruby is a programming language (to be fair, it's likely a mess, but I've definitely seen it be less mess).
When you look at business rules / requirements, it's common for 99% of them to be trivial. Of the remainder, 99% are only moderately complex.
If you have, say, fewer than 10k distinct rules, you probably don't have more than one that's really wicked.
However, if you have 100k rules, it's more likely than not that you have quite a few that are going to completely wreck your xml/json model.
XML didn’t fail because of some technical limitation. It failed because it tried to turn us all into language designers. At worst JSON asks you for a schema, and that was an afterthought in both cases.
It's a hard problem. Probably the hardest.
1. Part of compiler construction courses is to instill in the students the notion of metea-linguistic abstraction (SICP), namely to solve problems by creating and implementing domain-specific languages (DSLs) that permit declarative statements about the domain in a natural and therefore maintainable notation, which is separate from an engine that can interpret or compile it. Compiler classes are ideal to teach about DSLs because the topic is parsing and compiling/iterpreting anyhow, but not only that, they can see that compiler people do as they say: they use the techniques for compiler construction themselves, which is often but not always done using even more than one DSLs (one for lexers, one for grammars, sometimes even DSLs). Parser generators are also used outside of programming languages, for example in computational linguistics formal grammars are often used to model human language morphology, phonology or syntax (with ambiguous grammars). Tomita's GLR parsing - mentioned elsewhere in this thread - comes from that application area.
2. Another part of compiler construction tertiary education is to get across the utility of theory for practical applications and the closeness of theory and practice in computer science: Formal language theory is beautiful and well-developed, and to show to students that it is also useful because it gives runtime and space complexity guarantees and systematic approaches for reducing faulty implementations is a wonderful thing.