567
GIMP is gearing up for a massive upgrade (www.gimp.org)
submitted 2 months ago by to c/opensource@lemmy.ml
185 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 10 points 2 months ago* (last edited 2 months ago) (4 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

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] -3 points 2 months ago (3 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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 8 points 2 months ago* (last edited 2 months 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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 6 points 2 months ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •