For the file format, would have been JSON instead XML not the better format? Its lighter and easier to parse and write, meaning more performant than XML.

[–] schnurrito@discuss.tchncs.de 30 points 1 week ago (1 children)

IMHO: XML is superior as a document storage format. JSON is superior as a data transfer format.

[–] thingsiplay@lemmy.ml -5 points 1 week ago* (last edited 1 week ago) (2 children)

XML is not really superior to JSON as an image editing file format. EDIT: XML is better, if you want to keep a readable source format with markup. But that is not what a format for an image editing tool like GIMP should be needed for in my opinion.

[–] schnurrito@discuss.tchncs.de 15 points 1 week ago (1 children)

No, they are both not really suitable for that. But I don't see where the link in the OP implies they plan to store binary image data in XML, they're probably going to store that in a binary format and use XML to describe relationships and other metadata.

[–] CmykStudent@fosstodon.org 7 points 1 week ago

@schnurrito @thingsiplay Yes, the XML is for file structure descriptions not binary data.

The GEGL buffers we use for image data in GIMP can be synced across files, so this new format will allow us to quickly auto-save the image/layer/etc to file as you make edits. Still in-progress work, but it's really cool.

[–] mholiv@lemmy.world 10 points 1 week ago* (last edited 1 week ago) (1 children)

I’m gunna disagree with you XML comes with validators and versioning as part of the XML spec. You can validate XML files against XSD descriptors that can be published and even referenced by the XML file.

The only downside of XML over json is that XML is verbose AF.

Strict validators, versioning, checking, and definitions is EXACTLY what you want in a storage format.

ODF is also XML. It makes sense here.

More information for you: https://en.wikipedia.org/wiki/XML_Schema_(W3C)

https://en.wikipedia.org/wiki/OpenDocument

[–] thingsiplay@lemmy.ml -3 points 1 week ago (2 children)

JSON comes with builtin data formats that XML lacks, that's why you have such overhead with additional validation. Everything in XML is treated as strings, and there are lot of stuff like entities that is totally unneeded for a file format like in GIMP. XML Schema is needed because the format is extremely complicated unlike JSON, if you have no other validation. GIMP itself has validation builtin already.

[–] mholiv@lemmy.world 9 points 1 week ago* (last edited 1 week ago)

You have it mostly backwards. XML has like 40+ types that are all standardized. JSON only has the basic JS types. XML is a superset of JSON when it comes to types.

How would you represent a double float, or binary data, or a datatime in JSON. You would have to use strings in JSON. In XML you would use the xsd:double, xsd:binary, and xsd:dateTime.

JSON only works if you think in JavaScript. For languages with more complete / complex data systems it does not do unless you resort to the string thing.

For your information:

Easier to read: https://www.ibm.com/docs/en/jfsm/1.1.2.1?topic=queries-xsd-data-types

The official spec: https://www.w3.org/TR/xmlschema-2/

As for validation I think “right tool for the right job” is the best approach here. How do you know your validator is validating correctly? That’s the beauty of XML. Validation is part of the spec. XML is more complicated, but only because it’s more capable than json. Just like protobuf is more complicated than JSON. It’s also more complicated and not centered on JSON types.

[–] 4am@lemmy.zip 6 points 1 week ago (1 children)

JSON items don’t have attributes, which sometimes makes queries outside of a specific path or across domains difficult or impossible.

“But if you take the time to design your objects correctly…”

Or they could just choose the format that already does what is needed instead of worrying about building and maintaining serialization layers to shoehorn in a functionality that they could get for free by picking the correct format in the first place.

Also why are we having this argument? XML isn’t going away, REST already beat SOAP, and JSON is harder to read. Compressed XML is only about 10% larger than compressed JSON, and we’re talking about the metadata of a layered image file so that’s like 16kb vs 15kb.

[–] thingsiplay@lemmy.ml -2 points 1 week ago

As explained, its not about the compressed size only. I am talking about uncompressed data that is live patched.

[–] Zarobi@aussie.zone 9 points 1 week ago

I found a Stack Overflow thread where people discuss this and actually test it. Further down the page is a 2026 test. The results are it's basically the same, very little practical difference in normal usage. If you're auto saving a file every 30 seconds you will not notice any difference between XML and JSON.

Personally, I like XML more for data files like this. I would not reach for JSON as my first thought for deserealizing a complex object hierarchy. Stuff like, a polygon can have a drawing of type vector which can have n paths which each have exactly 2 points… easy to store and validate in XML. Quite messy and complicated in JSON.

<Drawing type="polygon">
  <Line color="#fed1aa">
    <Point x="6" y="7" />
    <Point x="69" y="420" />
  </Line>
</Drawing>

[–] deadcream@sopuli.xyz 6 points 1 week ago (1 children)

Performance doesn't matter unless you are dealing with gigabytes of xml. And ease of parsing/writing is irrelevant when it's done under the hood by the program.

[–] thingsiplay@lemmy.ml 5 points 1 week ago (1 children)

Performance matters a lot, because program can autosave in quick sessions after simple steps. Even more important if multiple images are edited or loaded. While this is not the biggest improvement, it is still something to keep in mind. Performance should always be a priority. Programs will keep expanding and add bloat over time, so its good to have a format like that in mind.

[–] deadcream@sopuli.xyz 3 points 1 week ago (1 children)

You should always measure first before blindly following dogmas. I doubt that the choice of serialization format is what dominates processor time in this case.

[–] thingsiplay@lemmy.ml 3 points 1 week ago* (last edited 1 week ago)

You should always measure first before blindly following dogmas.

Then you follow it by doubting it without measuring:

I doubt that the choice of serialization format is what dominates processor time in this case.

Also note I was not just speaking of today, but with future additions and changes. You can't measure the future, but you can plan ahead and build upon a good foundation, that the small format can be used for extending it in future. That's the idea. Also to test what you suggest they have to build the entire system years and waste lot of time and effort.

[–] l3mming@lemmy.world 1 points 1 week ago

Agreed. XML has been dead for at least 10 years. Still, at least it's not YAML.