3 ms·

How is it a fair response? Isn't it desirable to have a format that can be used by machines and humans at the same time? XSLT accomplishes what json-ld and sem

How is it a fair response? Isn't it desirable to have a format that can be used by machines and humans at the same time? XSLT accomplishes what json-ld and semantic html never managed.

otterley 1y ago
The response says that for every provided XML document URL, there is an existing equivalent HTML document URL that accomplishes the same outcome for the end user and that is strongly emphasized by the site's UX. The fact that humans rarely access the XML documents via common browsers is also evident from the available usage metrics. The question of abstract efficiency via reuse is academic. If the XML documents were the ones that users accessed most of the time, or were the only documents available, that might change the analysis. But that isn't the case.
- kuschku 1y ago
  By that same argument, we could deprecate PDF support, as almost every PDF content on the web has an equivalent and emphasized HTML version. Or we could deprecate support for .txt and .xml in the browser itself, for the same reasons. We obviously don't want that. It's valuable to have support for multiple formats, and it's especially valuable to have a single file that can be used by both machines and humans.
  - deleted 1y ago
    [deleted]
  - otterley 1y ago
    Metrics show that users frequently access text and PDF files in their browsers. They almost never access XML files, despite the purported benefit you mention. Not everything that has a benefit is accepted by customers. Some stuff just doesn't sell.
    - kuschku 1y ago
      Have you considered that the only users who access XML files might be a) at work (where you won't get telemetry) or b) techies, who also disable metrics? You can't just use the metrics of "what do people who don't know how to disable telemtry use?" to make decisions for everyone.
      - otterley 1y ago
        Where's your proof that it is in use sufficient to justify maintaining the functionality? If you have such data, take it to the decision makers. Nobody's going to make decisions based on hypotheticals in the presence of data. As more than one VP has said at my company: "In God I trust. Everyone else needs data."
        kuschku 1y ago
        I'm arguing that such decisions shouldn't be taken based on flawed metrics, and here you demand I produce my own flawed metrics to "prove" my point. This isn't really leading anywhere.
        otterley 1y ago
        By your logic, nobody should take an action unless the data that supports it is flawless. That's not how the world works and would lead to widespread decision paralysis. Most of the world's progress is based on taking calculated risks based on the information you do have, despite imperfections.
    - kuschku 1y ago
      So here's what you'd do if you wanted to have actual metrics. 1. Analyze which groups of users you've got, and how large they are 2. For each recorded metric, categorize it into the appropriate group 3. Weight each set of metrics by the actual sizes of each user group from step 1 If some users groups have no, or too little data, pay users in these groups to do surveys. Now you've got actual metrics telling you how many people will be affected. Going beyond that, measure how long each visit was, and how long each session was. If users don't agree, again, pay them to take surveys or to watch them browse. Now you can weight the metrics by how many individual sessions will be disrupted, and how much time you've cost users with your decision. And this is just the very basics of collecting proper metrics, as done by proper polling institutes. You could contract Nielsen (US) or GfK (DE) to do this for you, they've got decades of experience collecting such metrics for all kinds of industries. But "Number of page loads of opted in users" is a metric that only tells you how many ad views will be disrupted by a change.
- Brybry 1y ago
  https://www.congress.gov/bill/117th-congress/house-bill/3617 https://www.congress.gov/bill/117th-congress/house-bill/3617 isn't really a comparable link to https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... But I think that was maybe just a mistake? Maybe he meant https://www.congress.gov/bill/117th-congress/house-bill/3617/text/ih?format=xml https://www.congress.gov/bill/117th-congress/house-bill/3617...
- slipperydippery 1y ago
  Having a reasonably complete and well-performing set of XML tools available in the browser is really nice. The counterpoint seems to be "well it has Javascript so we don't need actual features since you can theoretically write anything in JS" but one of the nicest things about it was having that toolkit available to Javascript. You can spin up a DOM for arbitrary XML and apply a bunch of natively-compiled, fast tools to it, coordinating and supplementing that with JS. Then present that to the UI as HTML. It's very nice. I'm on team "the right move is to upgrade these, not remove them". If they want to remove things to simplify the spec I've got a list I'd suggest, but it's mostly stuff added in the last decade.
  - otterley 1y ago
    I'm sympathetic to the argument that the feature is an elegant one. But at the same time, maintaining it is not cost-free; every line of code written, imported, or linked poses an ongoing "tax" and/or risk. This is a garden-variety product management decision: is it worth the ongoing maintenance and risk? As a responsible PM, you have to weigh the costs against the benefits, and I think they've presented sufficient evidence users have voted "no" on the benefits. As I said in another thread, not everything of value or benefit gains meaningful adoption. A rational actor doesn't preserve everything of value for its own sake. At best, we call people who do "museum curators," and at worst, "hoarders."
    - slipperydippery 1y ago
      The people stewarding the Web platform have neglected a lot of nice things, among them this—a major version two major versions ahead of what's in browsers, is eight years old. That it still has any use on notable sites at all seems like a decent cue to at least try not neglecting it before declaring nobody wants to use it. ... however, it's mostly useful for doing things that owners of walled Web platforms have no interest in, like working with interoperable protocols & formats. They've been killing those through active moves and neglect for 15 years, so why would they do something that makes that easier & nicer?
      - 1y ago
JimDabell 1y ago
> XSLT accomplishes what json-ld and semantic html never managed. What are you talking about, it’s accomplished practically nothing‽ XSLT is a way to write code that takes one XML file and turns it into a different XML file. Its primary use case is to make RSS feeds look nicer in browsers. That’s it. It hasn’t solved the Semantic Web.

How is it a fair response? Isn't it desirable to have a format that can be used by machines and humans at the same time? XSLT accomplishes what json-ld and semantic html never managed.

otterley 1y ago

The response says that for every provided XML document URL, there is an existing equivalent HTML document URL that accomplishes the same outcome for the end user and that is strongly emphasized by the site's UX. The fact that humans rarely access the XML documents via common browsers is also evident from the available usage metrics. The question of abstract efficiency via reuse is academic. If the XML documents were the ones that users accessed most of the time, or were the only documents available, that might change the analysis. But that isn't the case.

kuschku 1y ago
By that same argument, we could deprecate PDF support, as almost every PDF content on the web has an equivalent and emphasized HTML version. Or we could deprecate support for .txt and .xml in the browser itself, for the same reasons. We obviously don't want that. It's valuable to have support for multiple formats, and it's especially valuable to have a single file that can be used by both machines and humans.
- deleted 1y ago
  [deleted]
- otterley 1y ago
  Metrics show that users frequently access text and PDF files in their browsers. They almost never access XML files, despite the purported benefit you mention. Not everything that has a benefit is accepted by customers. Some stuff just doesn't sell.
  - kuschku 1y ago
    Have you considered that the only users who access XML files might be a) at work (where you won't get telemetry) or b) techies, who also disable metrics? You can't just use the metrics of "what do people who don't know how to disable telemtry use?" to make decisions for everyone.
    - otterley 1y ago
      Where's your proof that it is in use sufficient to justify maintaining the functionality? If you have such data, take it to the decision makers. Nobody's going to make decisions based on hypotheticals in the presence of data. As more than one VP has said at my company: "In God I trust. Everyone else needs data."
      - kuschku 1y ago
        I'm arguing that such decisions shouldn't be taken based on flawed metrics, and here you demand I produce my own flawed metrics to "prove" my point. This isn't really leading anywhere.
        otterley 1y ago
        By your logic, nobody should take an action unless the data that supports it is flawless. That's not how the world works and would lead to widespread decision paralysis. Most of the world's progress is based on taking calculated risks based on the information you do have, despite imperfections.
  - kuschku 1y ago
    So here's what you'd do if you wanted to have actual metrics. 1. Analyze which groups of users you've got, and how large they are 2. For each recorded metric, categorize it into the appropriate group 3. Weight each set of metrics by the actual sizes of each user group from step 1 If some users groups have no, or too little data, pay users in these groups to do surveys. Now you've got actual metrics telling you how many people will be affected. Going beyond that, measure how long each visit was, and how long each session was. If users don't agree, again, pay them to take surveys or to watch them browse. Now you can weight the metrics by how many individual sessions will be disrupted, and how much time you've cost users with your decision. And this is just the very basics of collecting proper metrics, as done by proper polling institutes. You could contract Nielsen (US) or GfK (DE) to do this for you, they've got decades of experience collecting such metrics for all kinds of industries. But "Number of page loads of opted in users" is a metric that only tells you how many ad views will be disrupted by a change.
Brybry 1y ago
https://www.congress.gov/bill/117th-congress/house-bill/3617 https://www.congress.gov/bill/117th-congress/house-bill/3617 isn't really a comparable link to https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.xml https://www.congress.gov/117/bills/hr3617/BILLS-117hr3617ih.... But I think that was maybe just a mistake? Maybe he meant https://www.congress.gov/bill/117th-congress/house-bill/3617/text/ih?format=xml https://www.congress.gov/bill/117th-congress/house-bill/3617...
slipperydippery 1y ago
Having a reasonably complete and well-performing set of XML tools available in the browser is really nice. The counterpoint seems to be "well it has Javascript so we don't need actual features since you can theoretically write anything in JS" but one of the nicest things about it was having that toolkit available to Javascript. You can spin up a DOM for arbitrary XML and apply a bunch of natively-compiled, fast tools to it, coordinating and supplementing that with JS. Then present that to the UI as HTML. It's very nice. I'm on team "the right move is to upgrade these, not remove them". If they want to remove things to simplify the spec I've got a list I'd suggest, but it's mostly stuff added in the last decade.
- otterley 1y ago
  I'm sympathetic to the argument that the feature is an elegant one. But at the same time, maintaining it is not cost-free; every line of code written, imported, or linked poses an ongoing "tax" and/or risk. This is a garden-variety product management decision: is it worth the ongoing maintenance and risk? As a responsible PM, you have to weigh the costs against the benefits, and I think they've presented sufficient evidence users have voted "no" on the benefits. As I said in another thread, not everything of value or benefit gains meaningful adoption. A rational actor doesn't preserve everything of value for its own sake. At best, we call people who do "museum curators," and at worst, "hoarders."
  - slipperydippery 1y ago
    The people stewarding the Web platform have neglected a lot of nice things, among them this—a major version two major versions ahead of what's in browsers, is eight years old. That it still has any use on notable sites at all seems like a decent cue to at least try not neglecting it before declaring nobody wants to use it. ... however, it's mostly useful for doing things that owners of walled Web platforms have no interest in, like working with interoperable protocols & formats. They've been killing those through active moves and neglect for 15 years, so why would they do something that makes that easier & nicer?
    - 1y ago

JimDabell 1y ago

> XSLT accomplishes what json-ld and semantic html never managed. What are you talking about, it’s accomplished practically nothing‽ XSLT is a way to write code that takes one XML file and turns it into a different XML file. Its primary use case is to make RSS feeds look nicer in browsers. That’s it. It hasn’t solved the Semantic Web.