6 ms·

The article is about intentional killing XSLT/XML in the browser. I think it is evolutionary: devs switched to JSON, AI agents don't care at all - they can hand

The article is about intentional killing XSLT/XML in the browser. I think it is evolutionary: devs switched to JSON, AI agents don't care at all - they can handle anything; XML just lost naturally, like GOPHER

zzo38computer 1y ago
I think JSON is generally better than XML (although XML is better for some things, mostly it isn't), but JSON is not so good either; I think DER format is much better.
_heimdall 1y ago
The only reason AI agents don't care about XML is because the developers decided, yet again, to attempt to recreate the benefits of REST on top of JSON. That's been tried multiple times over the last two decades and it just ends up with a patchwork of conventions and rules defining how to jam a square peg into a round hole.
- afavour 1y ago
  Many years ago I tried very hard to go all-in on XML. I loved the idea of serving XML files that contain the data and an XSLT file that defined the HTML templates that would be applied to that XML structure. I still love that idea. But the actual lived experience of developing that way was a nightmare and I gave up. "Developers keep making this bad choice over and over" is a statement worthy of deeper examination. Why? There's usually a valid reason for it. In this instance JSON + JS framework of the month is simply much easier to work with.
  - molteanu 1y ago
    "Choice" is a big word here. It would imply "we've weighted the alternatives, the pros and cons, we've tested and measured different strategies and implementations and we came out with this conclusion: [...]." You know, like science and engineering. While oftentimes what happens is is "oh, this thing seems to be working. And it looks easy. Great! Moving on.."
  - bilog 1y ago
    Most of the issues of using client-side XSLT is that browsers haven't updated their implementations since v1 nor their tooling to improve debugging. Both of these issues are resolved improving the implementations and tooling, as pointed out by several commenters on the GH issue.
    - FeepingCreature 1y ago
      That kind of demonstrates why XSLT is a bad idea as well though. JSON has its corner cases, but mostly the standard is done. If you want to manipulate it, you write code to do so.
      - _heimdall 1y ago
        JSON correlates to XML rather than XSLT. As far as I'm aware, XML as a standard is already done as well. XSLT is more related to frontend frameworks like react. Where XML and JSON are ways of representing state, XSLT and react (or similar) are ways of defining how that state is converted to HTML meant for human consumption.
        bilog 1y ago
        Also, fun fact, XSLT 3 relies on XPath 3.1 which can also handle JSON.
        _heimdall 1y ago
        Ah, so it can! I've only ever used XSLT with built-in browser support, never even realized the latest would allow JSON to be rendered with XSLT!
        FeepingCreature 1y ago
        Yes but React is not built into the browser, that's kinda my point.
        _heimdall 1y ago
  - deleted 1y ago
    [deleted]
  - scotty79 1y ago
    XSLT is much nicer to use if you just create a very simple templating language that compiles to XSLT. Subset of XLST already has a structure of typical templating language. It can even be done with regexps. Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read.
- sharpfuryz 1y ago
  People have been building things differently for the last 10 years, using json/grpc/graphql (that's why replacing complex formats like xml/wsdl/soap with just JSON is a bad idea), so why train(spend money) AI for legacy tech?
isodev 1y ago
The problem is not XML vs. JSON. This is not about choosing the format to store a node app's configuration. This is about an entire corpus of standards, protocols that depend on this. The root problem for me is: 1) Google doing whatever they want with matters that affect every single human on the planet. 2) Google running a farse with "public feedback" program where they don't actually listen, or in this case ask for feedback after the fact. 3) Google not being truthful or introspective about the reasons for such a change, especially when standardized alternatives have existed for years. 4) Honestly, so much of standard, interoperable "web tech" has been lost to Chrome's "web atrocities" and IE before that... you'd think we've learned the lesson to "never again" have a dominant browser engine in the hands of a "for profit" corp.
- rapnie 1y ago
  Yes, this is the real issue, and it is a pity so many comments delve into json vs. xml and not on the title stating that "google is killing the open web". A new stage of the web is forming where Big Tech AI isn't just chatbots, but matured to offer fully operational end-to-end services. All AI-operated and served, up to tailor-made domain-specific UI. Then the corporations, winners in their market, don't have a need for open web anymore to slurp data from. All open web data absorbed, now fresh human creativity flows in exclusively via these service, directly feeding the AI systems.
  - quietbritishjim 1y ago
    There are a lot of comments focusing more on the specifics of XML and XSLT because that's what much of the article laboriously drones on about, despite its general title.
- StopDisinfo910 1y ago
  The narrative would be more compelling to me if Google didn’t fail to impose their technology on the web so many times. NaCL? Mozilla won this one. Wasm is a continuation of asm.js. Dart? It now compiles to Wasm but has mostly failed to replace js while Typescript filled the niche. Sure, Google didn’t care much for XML. They had a proper replacement for communication and simple serialisation internally in protobuf which they never actually try to push for web use. Somehow json ended up becoming the standard. I personally don’t give much credit to the theory of Google as a mastermind patiently under minding the open web for years via the standards. Now if we talk about how they have been pushing Chrome through their other dominant products and how they have manipulated their own products to favour it, I will gladly agree that there is plenty to be said.
mattlondon 1y ago
+1 I think XML "lost" some time ago. I really doubt anyone would chose to use it for anything new these days. I think, from my experience at least, that we keep getting these "component reuse" things coming around "oh you can use Company X's schema to validate your XML!" "oh you can use Company X's custom web components in your web site!" etc etc yet it rarely if ever seems to be used. It very very rarely ever feels like components/schemas/etc can be reused outside of their intended original use cases, and if they can they are either so trivially simple it's hardly worth the effort, or they are so verbose and cumbersome and abstracted trying to be all things to all people then it is a real pain to work with. (And for the avoidance of doubt I don't mean things like tailwind et Al here) I'm not sure who keeps dreaming these things up with this "component reuse" mentality but I assume they are in "enterprise" realms where looking busy and selling consulting is more important than delivering working software that just uses JSON :)
- MrVandemar 1y ago
  > I really doubt anyone would chose to use it for anything new these days. Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.
  - bryanrasmussen 1y ago
    I have a hilarious example of this. I was hired to consult at a large company that had "configurators" which were applications that decided all sorts of things for if you were building a new factory and needed to use this company's stuff for your factory, so for example one configurator would be a search for replacement part in your area - so if you are building a factory in Asia but you want to use a particular part but that part is has export restrictions for it from the U.S where it is manufactured you would use this tool to pick out the appropriate replacement part made somewhere in Asia. They had like 50 different configurators built at different times using different tech etc. (my memory is a bit fuzzy here as to how many they had etc. but it was a lot) So of course they wanted to make a solution for putting their codebase together and also make it easy to make new configurators. So they built a React application to take a configurator input format that would tell you how to build this application and what components to render and blah blah blah etc. Cool. But the configurator format was in JSON so they needed to make an editor for their configurator format. They didn't have a schema or anything like this they made up the format as they went along, and they designed the application as they went along by themselves, so application designed by programmers with all the wonder that description entails. That application at the end was just a glorified tree editor that looked like crap and of course had all sorts of functionality behavior and design mixed in with its need to check constraints for outputting a particular JSON structure at a particular point. Also programmed in React. There was about 10 programmers, including several consultants who had worked on this for over a year when I came along, and they were also shitting bricks because they had only managed to port over 3 configurators, and every time they ported a new one they needed to add in new functionality to the editor and the configurator compiler, and there was talk of redesigning the whole configurator editor cause it sucked to use. Obviously the editor part should have been done in XML. Then people could have edited the XML by learning to use XML spy, they could have described their language in XML schema real easy, and so forth. But no they built everything in React. The crowning hilarity - this application at most would ever be used by about 20 people in the world and probably not more than 10 people at all. I felt obligated by professional pride (and also by the fact that I could see no way could this project keep being funded indefinitely so it was to my benefit to make things work) to explain how XML would be a great improvement over this state of affairs but they wouldn't hear of it. After about 3 months on it was announced the project would be shut down in the next year. All that work wasted on an editor that could probably have been done by one expert in a month's time.
deleted 1y ago
[deleted]
bayindirh 1y ago
XML is not a file format only. It's a complete ecosystem built around that file. Protocols, verifiers, file formats built on top of XML. You can get XML and convert it to everything. I use it to model 3D objects for example, and the model allows for some neat programming tricks while being efficient and more importantly, human readable. Except being small, JSON is worst of both worlds. A hacky K/V store, at best.
- mortarion 1y ago
  I mean, at least JSON has a native syntax to indicate an array, unlike XML which requires that you tack on a schema. <MyRoot> <AnElement> <Item></Item> </AnElement> </MyRoot> Serialize that to a JavaScript object, then tell me, is "AnElement" a list or not? That's one of the reasons why XML is completely useless on the web. The web is full of XML that doesn't have a schema because writing one is a miserable experience.
  - bayindirh 1y ago
    This is why you can have attributes in a tag. You can make an XML file self explanatory. Consider the following example: <MyRoot> <AnElement type="list" items="1"> <Item>Hello, World!</Item> </AnElement> <MyRoot> Most parsers have type aware parsing, so that if somebody tucks string to a place where you expect integer, you can get an error or nil or "0" depending on your choice.
    - dminik 1y ago
      I had the displeasure of parsing XML documents (into Rust) recently. I don't ever want to do this again. JSON for all it's flaws is beautifully simple in comparison. A number is either a number or the document is invalid. Arrays are just arrays and objects are just objects. XML on the other hand is the wild west. This particular XML beast had some difficulty sticking to one thing. Take for instance lists. The same document had two different ways to do them: <Thing> <Name>...</Name> <Image>...</Image> <Image>...</Image> </Thing> <Thing> <Name>...</Name> <Images> <Image>...</Image> <Image>...</Image> </Images> </Thing> Various values were scattered between attributes and child elements with no rhyme or reason. To prevent code reuse, some element names were namespaced, so you might have <ThingName /> and <FooName />. To round off my already awful day, some numbers were formatted with thousands separators. Of course, these can change depending on your geographical location. Now, one could say that this is just the fault of the specific XML files I was parsing. And while I would partially agree, the fact that a format makes this possible is a sign of it's quality. Since there's no clear distinction between objects and arrays you have to pick one. Or multiple. Since objects can be represented with both attributes and children you have to pick one. Or both. Since there are no numbers in XML, you can just write them out any way you want. Multiple ways is of course preferable.
diggan 1y ago
> XML just lost naturally, like GOPHER Lost? The format is literally everywhere and a few more places. Hard to say something lost when it's so deeply embedded all over the place. Sure, most developers today reach for JSON by default, but I don't think that means every other format "lost". Not sure why there is always such a focus on who is the "winner" and who is the "loser", things can co-exists just fine.
- sharpfuryz 1y ago
  Do you use it daily in browser?
  - jeroenhd 1y ago
    Tons of APIs and applications work with XML. XSLT less so; that's more of a backend language.
  - MrVandemar 1y ago
    Immaterial. If the answer is either 'yes' or 'no', it makes no actual difference: gopher still exists, is still a thing, is still successful. It feels like you're just trying to move the goal-posts and redefine what 'lose' means and trying to lure the poster into a "gotcha".
    - sharpfuryz 1y ago
      It's not about a "gotcha." Browsers once supported the GOPHER protocol but dropped it around a decade ago. This serves as an analogy: if users don't use XSLT/XML daily, browsers may eventually drop support for XSLT - supporting features cost money
      - MrVandemar 1y ago
        That's not a great analogy. Firefox once supported RSS feeds as live bookmarks and dropped it, and not because people didn't use it, because people did use it and bemoaned its loss for years afterwards.
jon-wood 1y ago
> AI agents don't care at all And I don't care at all about the feelings of AI agents. That a tool that's barely existed for 15 minutes doesn't need a feature is irrelevant when talking about whether or not to continue supporting features that have been around for decades.
vidarh 1y ago
Agreed. Having actually built and deployed an app that could render entirely from XML with XSLT in the browser: I wouldn't do it again. Conceptually it was beautiful: We had a set of XSL transforms that could generate RSS, Atom, HTML, and a "cleaned up" XML from the same XML generated by our frontend, or you could turn off the 2-3 lines or so of code used to apply the XSL on the server side and get the raw XML, with the XSLT linked so the browser would apply it. Every URL became an API. I still like the idea, but hate the thought of using XSLT to do it. Because of how limited it is, we ended up having e.g. multiple representations of dates in the XML because trying to format dates nicely in XSLT for several different uses was an utter nightmare. This was pervasive - there was no realistic prospect of making the XML independent of formatting considerations.
- scotty79 1y ago
  XSLT is much nicer to use if you just create a very simple templating language that compiles to XSLT. Subset of XLST already has a structure of typical templating language. It can even be done with regexps. Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read. And while different date format seems to be a one off thing you'd prefer to deal with as late as possible in the stack, if you think broader, like addressing global audience in their respective languages and cultures, you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. Then doing just dates and perhaps numbers in the browser is just inconsistent. If browsers implemented https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange the web would get double digit percent lighter and faster and more accessible to humans and ai. But that would let you filter out ads orders of magnitude easier. So it won't happen.
  - vidarh 1y ago
    > You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. That's exactly what we didn't want. The XSL encoded the view. The "page" was a pure semantic representation of the data in XML that wherever possible were direct projections from the models stored and serialied internally in our system, and the XSL generated each of the different views - be it HTML, RSS, Atom, or a condensed/simplified XML view. The latter was necessary largely because the "raw" XML data was more verbose than needed due to the deficiencies of XSL. It's possible it'd be more pleasant to use XSL your way, but that way wouldn't have solved any issues we had a need to solve. > you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want. Today I'd simply use a mix of server-side transformations, CSS, and web components to achieve the same thing rather than try to force XSL to work for something it's so painful to use for.
int_19h 1y ago
Ironically LLMs are actually better at processing and especially outputting correct XML than they are at JSON.

zzo38computer 1y ago

I think JSON is generally better than XML (although XML is better for some things, mostly it isn't), but JSON is not so good either; I think DER format is much better.

_heimdall 1y ago

The only reason AI agents don't care about XML is because the developers decided, yet again, to attempt to recreate the benefits of REST on top of JSON. That's been tried multiple times over the last two decades and it just ends up with a patchwork of conventions and rules defining how to jam a square peg into a round hole.

afavour 1y ago
Many years ago I tried very hard to go all-in on XML. I loved the idea of serving XML files that contain the data and an XSLT file that defined the HTML templates that would be applied to that XML structure. I still love that idea. But the actual lived experience of developing that way was a nightmare and I gave up. "Developers keep making this bad choice over and over" is a statement worthy of deeper examination. Why? There's usually a valid reason for it. In this instance JSON + JS framework of the month is simply much easier to work with.
- molteanu 1y ago
  "Choice" is a big word here. It would imply "we've weighted the alternatives, the pros and cons, we've tested and measured different strategies and implementations and we came out with this conclusion: [...]." You know, like science and engineering. While oftentimes what happens is is "oh, this thing seems to be working. And it looks easy. Great! Moving on.."
- bilog 1y ago
  Most of the issues of using client-side XSLT is that browsers haven't updated their implementations since v1 nor their tooling to improve debugging. Both of these issues are resolved improving the implementations and tooling, as pointed out by several commenters on the GH issue.
  - FeepingCreature 1y ago
    That kind of demonstrates why XSLT is a bad idea as well though. JSON has its corner cases, but mostly the standard is done. If you want to manipulate it, you write code to do so.
    - _heimdall 1y ago
      JSON correlates to XML rather than XSLT. As far as I'm aware, XML as a standard is already done as well. XSLT is more related to frontend frameworks like react. Where XML and JSON are ways of representing state, XSLT and react (or similar) are ways of defining how that state is converted to HTML meant for human consumption.
      - bilog 1y ago
        Also, fun fact, XSLT 3 relies on XPath 3.1 which can also handle JSON.
        _heimdall 1y ago
        Ah, so it can! I've only ever used XSLT with built-in browser support, never even realized the latest would allow JSON to be rendered with XSLT!
      - FeepingCreature 1y ago
        Yes but React is not built into the browser, that's kinda my point.
        _heimdall 1y ago
- deleted 1y ago
  [deleted]
- scotty79 1y ago
  XSLT is much nicer to use if you just create a very simple templating language that compiles to XSLT. Subset of XLST already has a structure of typical templating language. It can even be done with regexps. Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read.
sharpfuryz 1y ago
People have been building things differently for the last 10 years, using json/grpc/graphql (that's why replacing complex formats like xml/wsdl/soap with just JSON is a bad idea), so why train(spend money) AI for legacy tech?

isodev 1y ago

The problem is not XML vs. JSON. This is not about choosing the format to store a node app's configuration. This is about an entire corpus of standards, protocols that depend on this. The root problem for me is: 1) Google doing whatever they want with matters that affect every single human on the planet. 2) Google running a farse with "public feedback" program where they don't actually listen, or in this case ask for feedback after the fact. 3) Google not being truthful or introspective about the reasons for such a change, especially when standardized alternatives have existed for years. 4) Honestly, so much of standard, interoperable "web tech" has been lost to Chrome's "web atrocities" and IE before that... you'd think we've learned the lesson to "never again" have a dominant browser engine in the hands of a "for profit" corp.

rapnie 1y ago
Yes, this is the real issue, and it is a pity so many comments delve into json vs. xml and not on the title stating that "google is killing the open web". A new stage of the web is forming where Big Tech AI isn't just chatbots, but matured to offer fully operational end-to-end services. All AI-operated and served, up to tailor-made domain-specific UI. Then the corporations, winners in their market, don't have a need for open web anymore to slurp data from. All open web data absorbed, now fresh human creativity flows in exclusively via these service, directly feeding the AI systems.
- quietbritishjim 1y ago
  There are a lot of comments focusing more on the specifics of XML and XSLT because that's what much of the article laboriously drones on about, despite its general title.
StopDisinfo910 1y ago
The narrative would be more compelling to me if Google didn’t fail to impose their technology on the web so many times. NaCL? Mozilla won this one. Wasm is a continuation of asm.js. Dart? It now compiles to Wasm but has mostly failed to replace js while Typescript filled the niche. Sure, Google didn’t care much for XML. They had a proper replacement for communication and simple serialisation internally in protobuf which they never actually try to push for web use. Somehow json ended up becoming the standard. I personally don’t give much credit to the theory of Google as a mastermind patiently under minding the open web for years via the standards. Now if we talk about how they have been pushing Chrome through their other dominant products and how they have manipulated their own products to favour it, I will gladly agree that there is plenty to be said.

mattlondon 1y ago

+1 I think XML "lost" some time ago. I really doubt anyone would chose to use it for anything new these days. I think, from my experience at least, that we keep getting these "component reuse" things coming around "oh you can use Company X's schema to validate your XML!" "oh you can use Company X's custom web components in your web site!" etc etc yet it rarely if ever seems to be used. It very very rarely ever feels like components/schemas/etc can be reused outside of their intended original use cases, and if they can they are either so trivially simple it's hardly worth the effort, or they are so verbose and cumbersome and abstracted trying to be all things to all people then it is a real pain to work with. (And for the avoidance of doubt I don't mean things like tailwind et Al here) I'm not sure who keeps dreaming these things up with this "component reuse" mentality but I assume they are in "enterprise" realms where looking busy and selling consulting is more important than delivering working software that just uses JSON :)

MrVandemar 1y ago
> I really doubt anyone would chose to use it for anything new these days. Use the correct tool for the job. If that tool is XML, then I use it instead of $ShinyThing.
- bryanrasmussen 1y ago
  I have a hilarious example of this. I was hired to consult at a large company that had "configurators" which were applications that decided all sorts of things for if you were building a new factory and needed to use this company's stuff for your factory, so for example one configurator would be a search for replacement part in your area - so if you are building a factory in Asia but you want to use a particular part but that part is has export restrictions for it from the U.S where it is manufactured you would use this tool to pick out the appropriate replacement part made somewhere in Asia. They had like 50 different configurators built at different times using different tech etc. (my memory is a bit fuzzy here as to how many they had etc. but it was a lot) So of course they wanted to make a solution for putting their codebase together and also make it easy to make new configurators. So they built a React application to take a configurator input format that would tell you how to build this application and what components to render and blah blah blah etc. Cool. But the configurator format was in JSON so they needed to make an editor for their configurator format. They didn't have a schema or anything like this they made up the format as they went along, and they designed the application as they went along by themselves, so application designed by programmers with all the wonder that description entails. That application at the end was just a glorified tree editor that looked like crap and of course had all sorts of functionality behavior and design mixed in with its need to check constraints for outputting a particular JSON structure at a particular point. Also programmed in React. There was about 10 programmers, including several consultants who had worked on this for over a year when I came along, and they were also shitting bricks because they had only managed to port over 3 configurators, and every time they ported a new one they needed to add in new functionality to the editor and the configurator compiler, and there was talk of redesigning the whole configurator editor cause it sucked to use. Obviously the editor part should have been done in XML. Then people could have edited the XML by learning to use XML spy, they could have described their language in XML schema real easy, and so forth. But no they built everything in React. The crowning hilarity - this application at most would ever be used by about 20 people in the world and probably not more than 10 people at all. I felt obligated by professional pride (and also by the fact that I could see no way could this project keep being funded indefinitely so it was to my benefit to make things work) to explain how XML would be a great improvement over this state of affairs but they wouldn't hear of it. After about 3 months on it was announced the project would be shut down in the next year. All that work wasted on an editor that could probably have been done by one expert in a month's time.

deleted 1y ago

[deleted]

bayindirh 1y ago

XML is not a file format only. It's a complete ecosystem built around that file. Protocols, verifiers, file formats built on top of XML. You can get XML and convert it to everything. I use it to model 3D objects for example, and the model allows for some neat programming tricks while being efficient and more importantly, human readable. Except being small, JSON is worst of both worlds. A hacky K/V store, at best.

mortarion 1y ago
I mean, at least JSON has a native syntax to indicate an array, unlike XML which requires that you tack on a schema. <MyRoot> <AnElement> <Item></Item> </AnElement> </MyRoot> Serialize that to a JavaScript object, then tell me, is "AnElement" a list or not? That's one of the reasons why XML is completely useless on the web. The web is full of XML that doesn't have a schema because writing one is a miserable experience.
- bayindirh 1y ago
  This is why you can have attributes in a tag. You can make an XML file self explanatory. Consider the following example: <MyRoot> <AnElement type="list" items="1"> <Item>Hello, World!</Item> </AnElement> <MyRoot> Most parsers have type aware parsing, so that if somebody tucks string to a place where you expect integer, you can get an error or nil or "0" depending on your choice.
  - dminik 1y ago
    I had the displeasure of parsing XML documents (into Rust) recently. I don't ever want to do this again. JSON for all it's flaws is beautifully simple in comparison. A number is either a number or the document is invalid. Arrays are just arrays and objects are just objects. XML on the other hand is the wild west. This particular XML beast had some difficulty sticking to one thing. Take for instance lists. The same document had two different ways to do them: <Thing> <Name>...</Name> <Image>...</Image> <Image>...</Image> </Thing> <Thing> <Name>...</Name> <Images> <Image>...</Image> <Image>...</Image> </Images> </Thing> Various values were scattered between attributes and child elements with no rhyme or reason. To prevent code reuse, some element names were namespaced, so you might have <ThingName /> and <FooName />. To round off my already awful day, some numbers were formatted with thousands separators. Of course, these can change depending on your geographical location. Now, one could say that this is just the fault of the specific XML files I was parsing. And while I would partially agree, the fact that a format makes this possible is a sign of it's quality. Since there's no clear distinction between objects and arrays you have to pick one. Or multiple. Since objects can be represented with both attributes and children you have to pick one. Or both. Since there are no numbers in XML, you can just write them out any way you want. Multiple ways is of course preferable.

diggan 1y ago

> XML just lost naturally, like GOPHER Lost? The format is literally everywhere and a few more places. Hard to say something lost when it's so deeply embedded all over the place. Sure, most developers today reach for JSON by default, but I don't think that means every other format "lost". Not sure why there is always such a focus on who is the "winner" and who is the "loser", things can co-exists just fine.

sharpfuryz 1y ago
Do you use it daily in browser?
- jeroenhd 1y ago
  Tons of APIs and applications work with XML. XSLT less so; that's more of a backend language.
- MrVandemar 1y ago
  Immaterial. If the answer is either 'yes' or 'no', it makes no actual difference: gopher still exists, is still a thing, is still successful. It feels like you're just trying to move the goal-posts and redefine what 'lose' means and trying to lure the poster into a "gotcha".
  - sharpfuryz 1y ago
    It's not about a "gotcha." Browsers once supported the GOPHER protocol but dropped it around a decade ago. This serves as an analogy: if users don't use XSLT/XML daily, browsers may eventually drop support for XSLT - supporting features cost money
    - MrVandemar 1y ago
      That's not a great analogy. Firefox once supported RSS feeds as live bookmarks and dropped it, and not because people didn't use it, because people did use it and bemoaned its loss for years afterwards.

jon-wood 1y ago

> AI agents don't care at all And I don't care at all about the feelings of AI agents. That a tool that's barely existed for 15 minutes doesn't need a feature is irrelevant when talking about whether or not to continue supporting features that have been around for decades.

vidarh 1y ago

Agreed. Having actually built and deployed an app that could render entirely from XML with XSLT in the browser: I wouldn't do it again. Conceptually it was beautiful: We had a set of XSL transforms that could generate RSS, Atom, HTML, and a "cleaned up" XML from the same XML generated by our frontend, or you could turn off the 2-3 lines or so of code used to apply the XSL on the server side and get the raw XML, with the XSLT linked so the browser would apply it. Every URL became an API. I still like the idea, but hate the thought of using XSLT to do it. Because of how limited it is, we ended up having e.g. multiple representations of dates in the XML because trying to format dates nicely in XSLT for several different uses was an utter nightmare. This was pervasive - there was no realistic prospect of making the XML independent of formatting considerations.

scotty79 1y ago
XSLT is much nicer to use if you just create a very simple templating language that compiles to XSLT. Subset of XLST already has a structure of typical templating language. It can even be done with regexps. Then simplicity becomes a feature. You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. Each template is simple and straightforward to write and read. And while different date format seems to be a one off thing you'd prefer to deal with as late as possible in the stack, if you think broader, like addressing global audience in their respective languages and cultures, you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. Then doing just dates and perhaps numbers in the browser is just inconsistent. If browsers implemented https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange the web would get double digit percent lighter and faster and more accessible to humans and ai. But that would let you filter out ads orders of magnitude easier. So it won't happen.
- vidarh 1y ago
  > You can write your page in pretty much pure HTML, or even pure HTML if you use comments or custom tags for block markers. That's exactly what we didn't want. The XSL encoded the view. The "page" was a pure semantic representation of the data in XML that wherever possible were direct projections from the models stored and serialied internally in our system, and the XSL generated each of the different views - be it HTML, RSS, Atom, or a condensed/simplified XML view. The latter was necessary largely because the "raw" XML data was more verbose than needed due to the deficiencies of XSL. It's possible it'd be more pleasant to use XSL your way, but that way wouldn't have solved any issues we had a need to solve. > you want to support that on the server so the data (dates, numbers, labels) lands on the client in the correct language and culture. That would've meant the underlying XML would need to mix view and model considerations, which is exactly what we didn't want. Today I'd simply use a mix of server-side transformations, CSS, and web components to achieve the same thing rather than try to force XSL to work for something it's so painful to use for.

int_19h 1y ago

Ironically LLMs are actually better at processing and especially outputting correct XML than they are at JSON.