2
ars1
3y

Why does .NET keep using XML for its project files? Just wondering if there is something I'm missing and there is a good reason why you'd want to use XML instead of JSON.

Comments
  • 0
    It’s fun and is easier to configure

    Says the one who barely even has visual studio
  • 0
    @dontbeevil disagree on readability. and transformations aren't really a big selling point IMHO.

    although i'd argue that yaml would be a better candidate than JSON. but as long as i never even have to think about manually editing the file in any meaningful way, i don't care.
  • 5
    They started to use a json based proj file for netcore but switched back since it caused massive problems for migrating existing projects and build systems meaning big users couldnot change to net core.

    And in the end they decided that any benefit if json did not out weight the negative impact.

    For new projects in companies with no existing infrastructure it worked either way.

    https://stevejgordon.co.uk/project-...

    And in the end, most devs don’t need to go into the proj files anyway
  • 1
    XML has better schema support, the named elements are generally better for backwards-compatible extensions than JSON's typeless objects, it solves the pyramid of doom very elegantly by integrating block-end comments into the language and it's both self-documenting with well named elements and supports comments since the dawn of time. On the other hand, the lack of element-valued named children is a pointless limitation that forces users to represent named children as child elements of type equal to child name, and this mixup of roles makes designing generic tooling needlessly difficult.

    This isn't an answer or counterargument, just my take on XML on general.
  • 2
    JSON also isn't very nice for hand writing configs. I hate YAML.

    If the config is simple enough, you could use something like TOML. That's a standardized INI like format
  • 1
    @Geoxion TOML is pretty cool, not from an engineering point of view, but it's decently feature rich and really pretty.
  • 1
    @lbfalvy most good tech is simple and boring. TOML is an example of simple and boring
  • 0
    @Geoxion TOML is definitely more complex than JSON since it has various redundant syntaxes and it lacks the ecosystem such as schemas (although I imagine JSONSchema works since it's the same structure). It's also less expressive than YAML and XML in absence of references. The main benefit is that it was always designed to be a human-friendly language so it has just that little extra complexity over JSON which makes it pleasant to write.
  • 0
    JSON is a subset of XML regarding features.

    Migration from super to subset isn't possible, as a subset doesn't have all features etc.

    JSON lacks eg namespaces - objects are simple, not complex

    YML / JSON are exchangeable.

    TOML is specialized on configuration, supporting sections - JSON / YML / XML are focused on object representation.
  • 0
    @IntrusionCM YML natively supports dates, binary, references, keys of complex types, sets and god knows what else. It's ridiculously complex.
  • 0
    @IntrusionCM As for JSON being a subset of XML, XML literally doesn't even support proper objects, the only composite attribute on each element is an array of strings and elements which can be constrained in a schema.
  • 0
    @IntrusionCM XML is a completely different datastructure from JSON and the only way to represent JSON-like elements is to define additional rules, but with additional rules any data notation can be converted to any other. The difference between them is simply that of convenience, except maybe JSON and TOML which are so similar they can probably be converted to each other using regex, so they can be considered isomorphic.
  • 1
    @lbfalvy well, TOML seems more like JSON and .ini-files had a very passionate night together at some point.
  • 0
    @lbfalvy

    https://w3.org/TR/xmlschema-2/...

    You could concert any JSON to XML - but XML to JSON is impossible, as XML is "in a nutshell" a descriptive language for any data.

    YML itself is "more restrictive".

    https://yaml.org/spec/1.2.2/...

    It has a base set of definitions and datatypes, but as it lacks namespaces and the ability to define own types, it's definitely a subset of XML.

    JSON is a subset of YML.

    https://yaml.org/spec/1.2.2/...

    TOML / JSON can't be interchanged.

    https://github.com/toml-lang/toml

    TOML wasn't designed to handle arbitrary data - it was specifically designed for configuration and simplified.

    Hence:

    XML > YML > JSON > TOML

    I love TOML btw for configuration, YML for configuration is a pain in the arse.
Add Comment