TAML for T3D

[Azaezel]

The difference with JSON and XML serialisers is they serialise to exactly what it says on the tin, not to several other file formats.

 

So basically, you're advocating for a more generalized term, like serialSource, or something along those lines to denote the subsystem isn't an explicit format-parser?

[buckmaster]

Maybe not that generic, but yes. Something like TAOS (torque app object serialisation) or TASL (torque app serialisation layer), but with less terrible acronyms. Also note that I'm not saying this is critical, just that it seems like a good idea. I know it involves renaming a bunch of stuff, which is annoying. While I'm making ideological ideas, I'd also rename .taml to just .xml because that's what it is, AFAICT. Though that one's less significant.

[JeffR]

Maybe not that generic, but yes. Something like TAOS (torque app object serialisation) or TASL (torque app serialisation layer), but with less terrible acronyms. Also note that I'm not saying this is critical, just that it seems like a good idea. I know it involves renaming a bunch of stuff, which is annoying. While I'm making ideological ideas, I'd also rename .taml to just .xml because that's what it is, AFAICT. Though that one's less significant.

 

I think i'd be OK with the system being called TASL, though I think it's somewhat low priority an issue.

That said, negatory on renaming taml format to xml. Remember, taml can be stored as xml, json or binary. May be worth calling it something other than taml, but it being changed to xml as an extension is pigeonholing it.

[buckmaster]

Remember, taml can be stored as xml, json or binary.

See, that's exactly the sort of thing this silly naming has made a problem of. TAML can serialise Torque objects to an XML file, a JSON file, or a binary file. TAML, by default, associates a different file extension with each of those formats. Though it looks like the programmer can overwrite this, so you could store JSON or binary in a .taml file if you wanted to.

Which, now I think about it, might be what you want if you want to serialise your assets as binary when you publish, for file size reasons. You don't want to have to rename your file paths when you switch format. Unless you can load a TAML file without specifying the extension, in which case it's a moot point.

What I'm saying is, currently, .taml usually means XML syntax. If you have a .taml file with JSON syntax, it will either be suffixed .json, or you have to write special logic to load it properly. So to avoid confusion between TAML the serialisation system and TAML the file format, which is actually just XML, I think writing to .xml would be preferable. That may be just me though :p.

[JeffR]

Remember, taml can be stored as xml, json or binary.

Though it looks like the programmer can overwrite this, so you could store JSON or binary in a .taml file if you wanted to.

 

See, I'd just embrace this behavior. I honestly completely forgot about the other file extensions because you don't need to use them if you don't want.

So embracing taml as the standard extension(or whatever we switch it to) would make sense to me.

[buckmaster]

Same file extension for different encodings? Sounds like a recipe for pain :(. Or do you mean getting rid of the non-XML encodings?

[rlranft]

Naw, if the system detects the encoding on load then who cares? The only real pain involved is when Billy Coder opens that .taml in a text editor and can't read it because he forgot he saved everything in binary mode.

I mean, do what you like with it but this really sounds like much ado about nothing.