upvote
You are right that your other examples (like s-expressions) are actually better than going with a fully custom language.

But as you note elsewhere, you were benefiting from the schema (DTD or XSD) being done elsewhere, which provided at least some validation: in my experience, building this layer (either in code or with a new DTD/XSD) without a proper XML schema is the hardest part in doing XML well.

By ignoring this cost, it appeared much cheaper than it really is.

I also think including proper XML parsing libraries (which are sometimes huge) is not always feasible either (think embedded devices, or even if you need to package it with your mobile app, the size will be relatively big).

reply
Why did you hardly engaged in the article on the subject of schema driven validation?
reply
I used xml and xpath a lot in the early 2000s when it was popular, and I never wrote or learned about schema validation. It's totally optional and I never found a need for it.

It's probably helpful for "standard data interchange between separate parties" use cases, in what I was doing I totally controlled the production and the interpretation of the xml.

reply
For this application, where you might have a lot of authors and apps working with the rule data, I think schema-based validation at some level is going to be a must if you don't want to end in sorrow.
reply
This is a good question! We do it, it works, and it's definitely an advantage of XML over alternatives. I just personally haven't had the time to dig in and learn it well enough to write a blog post about it. In practice I think people update the Fact Dictionary largely based on pattern matching, so that's what I focused on here.
reply