JSON is the problem, so this will continue to be a mess. Especially if you have hopes for this to be used by many many people and especially if you hope this can be ingested by many many different systems (e.g. every resume submission server for every company). You need to formalize the structure, so you need some sort of a formal schema. You may pretend you don't need one, but you kinda have one right now. The schema you have right now is your example structure and JavaScript comments.
You do realize that there is a JSON Schema specification, not to mention that JSON more naturally matches a program's object structure for serialization and deserialization. Generally speaking XML is more flexible than any object representation should be. Objects tend to have properties, and those properties may be a given type. But XML may define some properties as attributes, and others as a single /nested child element and others as 1+ child elements, or a child element with 1+ child elements. JSON is a natural, easy to understand and comprehend map without extra content that really isn't needed. JSON maps neatly to several object streaming systems, XML does not.
I'm sorry, but XML isn't some panacea of describing or encoding document structures. It's generally a collection of fragile verbose and overly complicated tools in a few given platforms to satisfy people that think enterprise programming means implementing every pattern that loosely fits their situation instead of clean, simple, elegant solutions that hide complexity where needed instead of creating more.
JSON + JSON-Schema is no more of a mess than XML + XML Schemas. And generally far more forgiving in any modern programing environment for client/server use.
> JSON + JSON-Schema is no more of a mess than XML + XML Schemas.
For this reason, many developers resist JSON-Schema. We already have one mess, if we need it - let's keep JSON clean! That's why we like it. A concrete example of keeping JSON clean was the removal of comments from the JSON spec to stop people using them as directives. If they had stayed, and JSON became complex and ugly and messy, would its popularity have continued?
However... the increasing prevalence of complex JSON formats may eventually make some form of JSON schema necessary.
That part on the homepage is a documentation generator I made for any given schema, it's suppose to be more of a go to reference manual but I guess that is unclear on the homepage.
All the modules have to pass the validator which is based off the formal specification in the repository. I think that is what you mean and as far as JSON is concerned, will keep at it for a bit and see how far it can go, if it's impossible hopefully a new standard in a correct format will take off and use some of the same tooling that we have built.
