Actually, referring to the .jmd format is just an excuse to tackle a much broader topic (and the title of this discussion isn’t very appropriate but couldn’t came up with anything else longer than 15 characters lol).
In a little project of mine I have to decide between defining a custom grammar for a file format or just an XSD and then take advantage of a good old xml. In the specific case of JM, what made the designer opt for the former for what concerns material defitions and instances? And in general, in which cases would you choose one option instead of the other?
j3md is not really a grammar file like an xsd. It does define what you can use in the j3m file, but it has no validation role at all.
Also it defines how the data from the j3m should be handled by defining the specific shader to use, and can also define default values for the material…
So it’s far from the logic of xsd to me.Not sure you will find hints for what you want to achieve by knowing why it’s been decided in the first place to make the j3md.
Also… IMO if you want to go that route ask yourself 1 question : Is this format will be portable or editable by a thrid party?
if that’s the case then go for it, xsd and xml will be fine and you’ll have an easy way to validate the incoming files.
Else you should not bother with it at all, and prefer a less verbose format… like json for example, if you want it to be readable by a human being.
Hi @nehon, thanks for the reply. What I meant was whether I should use something like ANTLR to generate a parser for a custom grammar, or choose the XML way of doing it, just adapting an XML to my needs. But I think what you then wrote on portability and editability is the discriminant factor here.
I was asking about the designing choices behind JM just to take advantage of what people more experienced than me (and involved in a “real” project) could think on the matter. For instance, why aren’t .j3md’s xml files instead of descriptive files following an ad hoc syntax?
The J3M(D) formats were designed to be written by humans (they were created before the SDK) and read by the engine.
The focus was on the ability to easily edit those files in a text editor since there were no material editing tools available at that time.
Because XML is a HORRIBLE file to hand edit. Just awful. So much extra typing just to keep the structure.
Still, nowadays, anyone who writes their own parser instead of just using something like Groovy (and creating a DSL there) or just doing it in Javascript, is kind of doing it the long way.