4 ms·

> I've never known any of XML's features to help with actually solving a business problem. Arm are publishing their full ISA processor specifications in XML, s

> I've never known any of XML's features to help with actually solving a business problem. Arm are publishing their full ISA processor specifications in XML, so it is 100% machine readable, see [1] for the actual specification and [2, 3] for why you want a machine readable ISA spec in the first place. Arm has been really ahead with this, and all the other processor manufacturer are playing catchup. I'm not saying that XML is the idea format for this purpose, but it clearly works for them. Which other format would you think is better for this purpose? Miminal requirements: works for gigabytes of data including graphics, automatic format checking, conversion to/from other formats, widely supported, easy to hire for, standard IDEs (e.g. VSCode plugins), long-term stability (processors need support for decades). [1] https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/architectures/cpu-architecture/a-p... [2] https://alastairreid.github.io/papers/fmcad2016-trustworthy.pdf https://alastairreid.github.io/papers/fmcad2016-trustworthy.... [3] https://alastairreid.github.io/uses-for-isa-specs/ https://alastairreid.github.io/uses-for-isa-specs/

lmm 5y ago
It may be "100% machine readable" in some sense, but I looked at a couple of those XML files at random and it seems like the majority of the content is a human-oriented markup document. Looking at it from the other side: why are they using XML rather than JSON? I don't think they're gaining much from schema or namespaces; I suspect the main reason is that that lets them have a single-file markup document that contains embedded data in a standardised way (by using XHTML and XSLT), which is sort of legitimate but only really for a niche archival use case (because normally having structured source data and some process that generates the HTML document from it is absolutely fine). Realistically you can achieve much the same thing by having a HTML file that embeds a chunk of JSON somewhere and then has a bit of javascript to render the page based on that JSON (i.e. filling the role of XSLT) and in most practical respects that's a lot better. The only missing part is that there's no defined standard for how you do that (it's not hard to do it, but there are different places where you could put the JavaScript and the JSON and for an archival document you want to be sure a future reader will know where to look) - and, given that XHTML+XSLT is widely seen as a dead end, I suspect there's not much enthusiasm for defining one.

lmm 5y ago

It may be "100% machine readable" in some sense, but I looked at a couple of those XML files at random and it seems like the majority of the content is a human-oriented markup document. Looking at it from the other side: why are they using XML rather than JSON? I don't think they're gaining much from schema or namespaces; I suspect the main reason is that that lets them have a single-file markup document that contains embedded data in a standardised way (by using XHTML and XSLT), which is sort of legitimate but only really for a niche archival use case (because normally having structured source data and some process that generates the HTML document from it is absolutely fine). Realistically you can achieve much the same thing by having a HTML file that embeds a chunk of JSON somewhere and then has a bit of javascript to render the page based on that JSON (i.e. filling the role of XSLT) and in most practical respects that's a lot better. The only missing part is that there's no defined standard for how you do that (it's not hard to do it, but there are different places where you could put the JavaScript and the JSON and for an archival document you want to be sure a future reader will know where to look) - and, given that XHTML+XSLT is widely seen as a dead end, I suspect there's not much enthusiasm for defining one.