7 ms·

My issue with xml for configuration files is not understanding when to use elements vs attributes to describe data. The nice thing about JSON, TOML, and YAML i

My issue with xml for configuration files is not understanding when to use elements vs attributes to describe data. The nice thing about JSON, TOML, and YAML is they have implicit structures for arrays and key/values encoded within them. XML has a lot of different ways of representing data that way, which is what makes it a challenging configuration file format.

wokkel 3y ago
The main reason i avoid any typeless language is dates... how do i represent a date/time including a time zone has been badly reinvented so many times. A string type is never the way to go there in my opinion.
- bradgessler 3y ago
  What’s the best representation you’ve seen for dates?
  - stackedinserter 3y ago
    UNIX timestamp. Plus timezone string, in separate field/column, if it's important for the use case (like calendar events, etc).
  - XorNot 3y ago
    Epoch time + GPS coordinates. That's as unambiguous as you could possibly make it IMO.
  - taeric 3y ago
    Hasn't https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 basically won, at this point?
- Smaug123 3y ago
  One of the classic lessons of the Falsehoods Programmers Believe about Time is that in general you can't correctly do better than simply storing the user's input (and the instant and place they entered it from) verbatim, unless you know something more about what they were entering. It's usually fine to store times in the past as a timestamp since the epoch plus a location, but the meaning of "2025-01-28 15:00 in Europe/London, for the purpose of a meeting that's being hosted there but is accessible by video call" is much more subject to change when e.g. countries change time zone. It's also not necessarily the same as "the absolute point in time 2025-01-28 15:00 assuming London's time zones stay as predicted since I entered this on 2023-09-21" or "2025-01-28 15:00 in Europe/London, for the purposes of a meeting that's being hosted in Lisbon but which I'm accessing by video call from London" (because then the Lisbon local time is the source of truth, not the London one, if Lisbon changes time zone).
KnobbleMcKnees 3y ago
That arrays point is such a weakness in XML that I rarely see addressed. Arrays and lists are such a common data structure in almost every programming language of the past 40 years that not having first class syntax for representing them is absurd and a huge weakness that makes XML a non-starter for me.
- chii 3y ago
  > not having first class syntax for representing them i think you're mixing representation of xml data vs the representation of them in a programming language. XML does have arrays. They care called child elements.
  - nickpp 3y ago
    Aren't XML child elements pretty much the most verbose way you can represent an array though?
    - krab 3y ago
      I think the verbosity is not a problem. For example if you compare ["string1", "string2"] to <list> <e>string1</e> <e>string2</e> </list> then each element has about four bytes overhead (<e> instead of " and </e> instead of ",) plus some overhead for the list itself that may be offset by putting the name of the list itself into the element. However, the issue is that you have to write a custom parser. There is no direct mapping between your data structure and the XML file. This developer ergonomics is a big win for JSON and consequently YAML.
      - chii 3y ago
        > There is no direct mapping between your data structure and the XML file. i think that's by design tbh. it's only a big win for JSON (and YAML) because the default case works OK - but every time someone has a problem parsing numbers in JSON (because the value is bigger than Integer.MAX in the host language), this is the cause.

wokkel 3y ago

The main reason i avoid any typeless language is dates... how do i represent a date/time including a time zone has been badly reinvented so many times. A string type is never the way to go there in my opinion.

bradgessler 3y ago
What’s the best representation you’ve seen for dates?
- stackedinserter 3y ago
  UNIX timestamp. Plus timezone string, in separate field/column, if it's important for the use case (like calendar events, etc).
- XorNot 3y ago
  Epoch time + GPS coordinates. That's as unambiguous as you could possibly make it IMO.
- taeric 3y ago
  Hasn't https://en.wikipedia.org/wiki/ISO_8601 https://en.wikipedia.org/wiki/ISO_8601 basically won, at this point?
Smaug123 3y ago
One of the classic lessons of the Falsehoods Programmers Believe about Time is that in general you can't correctly do better than simply storing the user's input (and the instant and place they entered it from) verbatim, unless you know something more about what they were entering. It's usually fine to store times in the past as a timestamp since the epoch plus a location, but the meaning of "2025-01-28 15:00 in Europe/London, for the purpose of a meeting that's being hosted there but is accessible by video call" is much more subject to change when e.g. countries change time zone. It's also not necessarily the same as "the absolute point in time 2025-01-28 15:00 assuming London's time zones stay as predicted since I entered this on 2023-09-21" or "2025-01-28 15:00 in Europe/London, for the purposes of a meeting that's being hosted in Lisbon but which I'm accessing by video call from London" (because then the Lisbon local time is the source of truth, not the London one, if Lisbon changes time zone).

KnobbleMcKnees 3y ago

That arrays point is such a weakness in XML that I rarely see addressed. Arrays and lists are such a common data structure in almost every programming language of the past 40 years that not having first class syntax for representing them is absurd and a huge weakness that makes XML a non-starter for me.

chii 3y ago
> not having first class syntax for representing them i think you're mixing representation of xml data vs the representation of them in a programming language. XML does have arrays. They care called child elements.
- nickpp 3y ago
  Aren't XML child elements pretty much the most verbose way you can represent an array though?
  - krab 3y ago
    I think the verbosity is not a problem. For example if you compare ["string1", "string2"] to <list> <e>string1</e> <e>string2</e> </list> then each element has about four bytes overhead (<e> instead of " and </e> instead of ",) plus some overhead for the list itself that may be offset by putting the name of the list itself into the element. However, the issue is that you have to write a custom parser. There is no direct mapping between your data structure and the XML file. This developer ergonomics is a big win for JSON and consequently YAML.
    - chii 3y ago
      > There is no direct mapping between your data structure and the XML file. i think that's by design tbh. it's only a big win for JSON (and YAML) because the default case works OK - but every time someone has a problem parsing numbers in JSON (because the value is bigger than Integer.MAX in the host language), this is the cause.