• Takumidesh@lemmy.world
      0·
      2 months ago

      I hate writing and reading xml compared to json, I don’t really care if one is slightly leaner than the other. If your concern is the size or speed you should probably be rethinking how you serialize the data anyway (orotobuff/DB)

  • ZILtoid1991@lemmy.world
    0·
    2 months ago

    XML has its strengths as a markdown format. My own formatted text format ETML is based on XML, as I could recycle old HTML conventions (still has stylesheet as an option), and I can store multiple text blocks in an XML file. It’s not something my main choice of human readable format SDL excels at, which itself has its own issues (I’m writing my own extensions/refinements for it by the name XDL, with hexadecimal numbers, ISO dates, etc.).

  • AeonFelis@lemmy.worldEnglish
    0·
    2 months ago

    XML is good for markup. The problem is that people too often confuse “markup” and “serialization”.

      • clb92@feddit.dkEnglish
        0·
        2 months ago

        Lots or file formats are just zipped XML.

        I was reverse engineering fucking around with the LBX file format for our Brother label printer’s software at work, because I wanted to generate labels programmatically, and they’re zipped XML too. Terrible format, LBX, really annoying to work with. The parser in Brother P-Touch Editor is really picky too. A string is 1 character longer or shorter than the length you defined in an attribute earlier in the XML? “I’ve never seen this file format in my life,” says P-Touch Editor.

  • Anna@lemmy.ml
    0·
    2 months ago

    Is this a tactic used by skynet to lure all humans together and then…BANG!!!

  • it_depends_man@lemmy.worldDeutsch
    0·
    2 months ago

    It is very cool, specifically as a human readable mark down / data format.

    The fact that you can make anything a tag and it’s going to be valid and you can nest stuff, is amazing.

    But with a niche use case.

    Clearly the tags waste space if you’re actually saving them all the time.

    Good format to compress though…

    • CanadaPlus@lemmy.sdf.org
      0·
      2 months ago

      I think we did a thread about XML before, but I have more questions. What exactly do you mean by “anything can be a tag”?

      It seems to me that this:

      <address>
    <street_address>21 2nd Street</street_address>
    <city>New York</city> 
    <state>NY</state>
    <postal_code>10021-3100</postal_code>
</address>

      Is pretty much the same as this:

        "address": {
    "street_address": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postal_code": "10021-3100"
  },

      If it branches really quickly the XML style is easier to mentally scope than brackets, though, I’ll give it that.

      • ClassifiedPancake@discuss.tchncs.de
        0·
        2 months ago

        Since XML can have attributes and children, it’s not as easy to convert to JSON.

        Your JSON example is more akin to:

        <address street_address="21 2nd Street" city="New York" ...></address>
        • CanadaPlus@lemmy.sdf.org
          0·
          2 months ago

          Hmm, so in tree terms, each node has two distinct types of children, only one of which can have their own children. That sounds more ambiguity-introducing than helpful to me, but that’s just a matter of taste. Can you do lists in XML as well?

      • it_depends_man@lemmy.worldDeutsch
        0·
        2 months ago

        I’m not sure now that I think about it, but I find this more explicit and somehow more free than json. Which can’t be true, since you can just

        {"anything you want":{...}}

        But still, this:

        <my_custom_tag>
<this> 
<that>
<roflmao>
...

        is all valid.

        You can more closely approximate the logical structure of whatever you’re doing without leaving the internal logic of the… syntax?

        <car>
<tyre> air, <valve>closed</valve>  </tyre>
<tyre> air, <valve>closed</valve>  </tyre>
<tyre>      <valve>open</valve>  </tyre>
<tyre> air, <valve>closed</valve>  </tyre>
</car>

        Maybe I just like the idea of a closing tag being very specific about what it is that is being closed (?). I guess I’m really not sure, but it does feel nicer to my brain to have starting and closing tags and distinguishing between what is structure, what is data, what is inside where.

        My peeve with json is that… it doesn’t properly distinguish between strings that happen to be a number and “numbers” resulting in:

        myinput = {"1":"Hello",1:"Hello"}
tempjson = json.dumps(myinput)
output = json.loads(tempjson)
print(output)
>>>{'1': 'Hello'}

        in python.

        I actually don’t like the attributes in xml, I think it would be better if it was mandatory that they were also just more tagged elements inside the others, and that the “validity” of a piece of xml being a certain object would depend entirely on parsing correctly or not.

        I particularly hate the idea of attributes in svg, and even more particularly the way they defined paths.

        https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths#curve_commands

        It works, but I consider that truly ugly. And also I don’t understand because it would have been trivial to do something like this:

        <path><element>data</element><element>data</element></path>
        • CanadaPlus@lemmy.sdf.org
          0·
          2 months ago

          Maybe I just like the idea of a closing tag being very specific about what it is that is being closed (?).

          That’s kind of what I was getting at with the mental scoping.

          My peeve with json is that… it doesn’t properly distinguish between strings that happen to be a number and “numbers"

          Is that implementation-specific, or did they bake JavaScript type awfulness into the standard? Or are numbers even supported - it’s all binary at the machine level, so I could see an argument that every (tree) node value should be a string, and actual types should be left to higher levels of abstraction.

          I actually don’t like the attributes in xml, I think it would be better if it was mandatory that they were also just more tagged elements inside the others, and that the “validity” of a piece of xml being a certain object would depend entirely on parsing correctly or not.

          I particularly hate the idea of attributes in svg, and even more particularly the way they defined paths.

          I agree. The latter isn’t even a matter of taste, they’re just implementing their own homebrew syntax inside a tag, circumventing the actual format, WTF.

    • Caveman@lemmy.world
      0·
      2 months ago

      I don’t mind xml as long as I don’t have to read or write it. The only real thing I hate about xml is that an array of one object can mistaken for a property of the parent instead of a list

    • ByteJunk@lemmy.world
      0·
      2 months ago

      I disagree, with a passion.

      It is soooo cluttered, so much useless redundant tags everywhere. Just give JSON or YAML or anything really but XML…

      But to each their own i guess.

    • Gremour@lemmy.world
      0·
      2 months ago

      YAML for human-written files, JSON for back-to-front and protobuf for back-to-back. XML is an abomination.

    • lemmesay@discuss.tchncs.de
      0·
      2 months ago

      coral by cohere

      no wait, it’s perplexity, I remember the logo.
      you can try their labs version which gives to access to latest and beefy models like llama3.1 70b

  • Fontasia@feddit.nl
    0·
    2 months ago

    OH HEY EVERYONE, EVERYONE, THIS GUY LIKES JSON

    Fuck you and your unstructured garbage.