AI's take on XML

Some data formats are easy for humans to read but difficult for computers to efficiently parse. Others, like packed binary data, are dead simple for computers to parse but borderline impossible for a human to read.
XML bucks this trend and bravely proves that data formats do not have to be one or the other by somehow managing to be bad at both.
- The thing is, it was never really intended as a storage format for plain data. It's a markup language, so you're supposed to use it for describing complex documents, like it's used in HTML for example. It was just readily available as a library in many programming languages when not much else was, so it got abused for data storage a lot.
  
  That's why professionals use XML or JSON for this kind of projects and SQL for that kind of projects. And sometimes even both. It simply depends on the kind of problem to solve.
- Strong competition from yaml and json on this point however
  
  JSON not supporting comments is a human rights violation
  
  Alright, the YAML spec is a dang mess, that I'll grant you, but it seems pretty easy for my human eyes to read and write. As for JSON -- seriously? That's probably the easiest to parse human-readable structured data format there is!
- Just a while ago, I read somewhere: XML is like violence. If it doesn't solve your problem, maybe you are not using it enough.
- There are people who find XML hard to read?
  
  Over time I have matured as a programmer and realize xml is very good to use sometimes, even superior. But I still want layers between me and it. I do output as yaml when I have to see what’s in there
  
  I see you've never worked with SOAP services that have half a dozen or more namespaces.
  
  Depends on how complex it is. Ever see the XML behind SharePoint? 🤮

I mean, it's not wrong...
- Disagree. I prefer XML for config files where the efficiency of disk size doesn't matter at all. Layers of XML are much easier to read than layers of Json. Json is generally better where efficiency matters.
  
  TOML or bust
  
  Aren't most XML parsers faster than JSON parsers anyway?
- Wishful thinking

Wow, that's a very passive aggressive reaction. I enjoyed a lot.
- This is what happens when stack overflow is used for training.
  
  Not long before AI just tells me to google it, or read the manual.
  
  This is what happens when people make content for points.
  OP already admitted he made it up.

- IMHO: XML is a file format, JSON is a data transfer format. Reinventing things like RSS or SVG to use JSON wouldn't be helpful, but using XML to communicate between your app's frontend and backend wouldn't be either.
  
  We were using XML for that before JSON.
- That's my biggest peev about JSON actually. No comments!! WTH!
  
  On one hand I agree, on the other hand I just know that some people would immediately abuse it and put relevant data into comments.
  
  There's comments in the specs and a bunch of parsers that actually inore //
- { "key": "six", "value": 6, "comment": "6 is a bad number. Use five." }
  
  Please don't. If you need something like json but with comments, then use YAML or TOML. Those formats are designed to be human-readable by default, json is better suited for interchanging information between different pieces of software. And if you really need comments inside JSON, then find a parser that supports // or /* */ syntax.
- And there are some truly magic tools.
  XSDs are far from perfect, but waaay more powerful than json schema.
  XSLT has its problems, but completely transforming a document to a completely different structure with just a bit of text is awesome. I had to rewrite a relatively simple XSLT in Java and it was something like 10 times more lines.
  
  And don't forget about namespaces. Look at formats like HAL and ODATA that try to add HATEOAS onto JSON.
- People may hate on SOAP but I've never had issues with setting up a SOAP client
- I came into the industry right when XML fever had peaked as was beginning to fall back. But in MS land, it never really went away, just being slowly cannibalize by JSON.
  You're right though, there was some cool stuff being done with xml when it was assumed that it would be the future of all data formats. Being able to apply standard tools like XLT transforms, XSS styling, schemas to validate, and XPath to search/query and you had some very powerful generic tools.
  JSON has barely caught up to that with schemes and transforms. JQ lets you query json but I don't really find it more readable or usable than XPath. I'm sure something like XLT exists, but there's no standardization or attempt to rally around shared tools like with XML.
  That to me is the saddest thing. VC/MBA-backed companies have driven everyone into the worst cases of NIHS ever. Now there's no standards, no attempts to share work or unify around reliable technology. Its every company for themselves and getting other people suckered into using (and freely maintaining) your tools as a prelude to locking them into your ecosystem is the norm now.

a wate of time

finally accurate ai
- Except for obvious typos
- XML is fine. Namespaces have a special place in hell though

A word document is xml
- zipped xml!
  
  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.
  
  The future if text documents were Json:
  City_pic.png.xml

I hate writing xml with a passion
- If you are writing it then you are doing it wrong.
  
  I hate writing a serialized format
  I mean, that's why it's serialized. It's not supposed to be written by hand, that's why you have a deserializer. 🤦
- What about writing in xml without any passion ?
  
  This is fine.

It’s not a waste of time… it’s a waste of space. But it does allow you to “enforce” some schema. Which, very few people use that way and so, as a data store using JSON works better.
Or… we could go back to old school records where you store structs with certain defined lengths in a file.
You know what? XML isn’t looking so bad now.
If you want to break the AI ask instead what regex you should use to parse HTML.
- Had to work with a fixed string format years ago. Absolute hell.
  Something like 200 variables, all encoded in fixed length strings concatenated together. The output was the same.
  ...and some genius before me used + instead of stringbuilders or anything dignified, so it ran about as good as lt. Dan.
  
  Oof. That sounds horrible
  
  We slowly need to interface with an app at work that uses fixed-width too. It does not sound that bad if you hear it but it sucks to figure out where you are missing whitespace when most fields are not used and therefore all whitespace. Oh, and of course there are a lot of fields, also are aligned/formatted differently based on their type and has thin/no/wrong documentation. And I have yet to find a simple but decent "debugger".

wate

I'm starting to like this AI thing...

I'm sorry which LLM is this? What are its settings? How'd you get that out of it?
And how did it give sources?
- I’m sorry which LLM is this?
  It's perplexity.ai. I like it because it doesn't require an account and because it can search the internet. It's like microsoft's bing but slightly less cringe.
  How’d you get that out of it?
  The screenshot is fake. I used Inspect Element.
  
  perplexity.ai
  Like DuckDuckGo's AI's, but with sources? Sounds cool, thanks!
  fake
  Ah... Too bad (:
- The answer is not real. The tool, on the other hand, is called Perplexity. It "understands" your question, searches the web, and gives you a summary, citing all the relevant sources.

RSS/ATOM has to be the best thing to come out of XML

XML is good for markup. The problem is that people too often confuse "markup" and "serialization".
- Too redundant, just use S-exprs.
  (Mostly joking, but in some cases...)
  
  Unironically.
  Given the choice between S-expressions and XML, I will choose S-expressions.

BASED. What is the name of this AI? I want to use this.
- 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

Listen we all know deep down the solution is to try to parse it with regex

stuff like this is how reddit found out their users comments were being used 😂

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...
- 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.
  
  YAML
  To each their own indeed.
  ;)
- 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.
  
  Since XML can have attributes and children, it's not as easy to convert to JSON.
  Your JSON example is more akin to:
  `xml
  
  <address street_address="21 2nd Street" city="New York" ...></address> `
  
  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>
- 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
- YAML for human-written files, JSON for back-to-front and protobuf for back-to-back. XML is an abomination.
  
  YAML is good for files that have a very flexible structure or need to define a series of steps. Like github workflows or docker-compose files. For traditional config files with a more or less fixed structure, TOML is better I think
  
  Having an easy on the eyes markdown that is also easy to parse would be cool.
  But YAML does these things:
  https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell
  which are not excusable, for any reason.

AI is starting to get really smart

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

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.).

Balisage Paper: Fat Markup: Trimming the Fat Markup Myth one calorie at a time
https://www.balisage.net/Proceedings/vol10/html/Lee01/BalisageVol10-Lee01.html
XML is a fine format in comparison to JSON.
- 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)
  
  I mean we have a generation that thinks XML is bloated & JSON is superior but those two formats are about the same on performance & compressed size--which was the point. The non-plaintext-readable formats are superior along a lot of metrics but harder to debug & ultimately less common.

OH HEY EVERYONE, EVERYONE, THIS GUY LIKES JSON
Fuck you and your unstructured garbage.