5 ms·

> Invisible XML (ixml) is a method for treating non-XML documents as if they were XML, > enabling authors to write documents and data in a format they prefer w

> Invisible XML (ixml) is a method for treating non-XML documents as if they were XML, > enabling authors to write documents and data in a format they prefer while providing XML for processes that are more effective with XML content. Interesting although this seems a little out of date because xml seems to one of the least desirable data formats for modern programming languages. Maybe this is more useful for legacy enterprise use cases that I don’t know about.

zapperdulchen 4y ago
There are XML workflows in technical documentation outside of software development where something like this could be of interest.
gavinray 4y ago
The fact that it's XML is not super relevant -- what you're working with in code is a tree structure that may as well be JSON or YAML This is essentially a way to write grammars for things and get the ability to parse them as trees in a common format that is interchangeable with things like JSON. I honestly don't see much of a difference between this, and something like a PEG grammar where you do this: let parsed = peg.parse(input, grammar) let xml = json2xml(parsed)
tokinonagare 4y ago
XML still has few advantages over JSON: comments, namespaces, a canonical form and slightly better extensibility.
- tartoran 4y ago
  At the expense of excessive verbosity. I used xml and still do to this day and it is one of my least favorite formats to read and edit.
- mpyne 4y ago
  JSON either has those (namespaces, extensibility) or the advantage is slight at best (comments, canonical form). There is a real advantage of XML over JSON not mentioned though, which is its usefulness in annotating computer-readable data into an otherwise human-editable document. There's not a lot of these cases, and where they're at you're probably still better off using AsciiDoc, Markdown or even HTML instead, but those use cases are out there and JSON is awful for those.
  - mcswell 4y ago
    "the advantage is slight at best (comments...)" I suppose that's true if the data is generated by machine and consumed by machine, and never edited or looked at by humans. But JSON seems to be used in a lot of datasets that humans do touch, like config files that you can edit. Visual Studio Code is one such user, and I've had to edit my own VSC config files. And I use comments, because http://catb.org/~esr/writings/unix-koans/prodigy.html http://catb.org/~esr/writings/unix-koans/prodigy.html. Fortunately, VSC allows comments between a // and a following newline.
    - mpyne 4y ago
      > Fortunately, VSC allows comments between a // and a following newline. Yes, that's my point. If a human is required to look at the JSON it's not hard to find a parser that permits comments. So of course it would be supported if it was actually needed. Even without that though, you can do something like the trick I used in a JSON-based format: { "__comment": "For help with this file, go to http://wiki.example.com/ http://wiki.example.com/...", ... "foo": "..." } That does have the problem that your programs processing the JSON need to strip out keys with that name if it would interfere with the program. So it's probably easier just to add the line of code in your parser saying to permit comments. Meanwhile, XML comments have issues of their own, as you have to be familiar with SGML rules on how -- are handled to safely use or edit XML comments. So while they are nice to have it's not as if they have no nuance either.
  - argomo 4y ago
    I'd add that another advantage of XML is that you get a powerful set of tools that are readily accessible across all "working" programming languages, often provided by first party libraries. Plus a lot of developers (and text editors) know the basic syntax. Granted, JSON has achieved this same level of universality, but everything else (excepting perhaps CSV files) either suffers from obscurity or from weak/ambiguous/competing specifications. The dream of semantically rich documents that XML provides (like, say, being able to cleanly interweave MathML, SVG, and XHTML in one document) is unmatched. I think we'd see a lot more XML usage if it hasn't been over-promised, over-delivered (WS-*), and over-used (enterprise Java). If XML had stuck to its lane (making a schema language like RelaxNG instead of XmlSchema, for one thing) it wouldn't have left such a bad taste in so many people's mouths.
- Dylan16807 4y ago
  Surely you could lay out a canonical form for JSON in like five minutes? Oh, here: https://www.rfc-editor.org/rfc/rfc8785 https://www.rfc-editor.org/rfc/rfc8785 No duplicates, no whitespace, sort the keys, copy number serialization from javascript, a couple other little details.
  - tokinonagare 4y ago
    > Published:June 2020 This only two years old while JSON is in common usage for more than a decade... Without a spec there's dozen way to achieve it, for example by sorting keys using UTF-8 instead of UTF-16 values like done in this document, and the slightest difference would break things when used with crypto.
    - Dylan16807 4y ago
      If you're doing something cryptographic you need a spec for that anyway, so the extra work to specifying something like json sort order doesn't seem like it's a major factor to me.
      - tokinonagare 4y ago
        There's a spec for that already for XML: Signed XML. And the tooling that supports it, for instance on the .NET platform. So no need to create yet another spec and tools.
        Dylan16807 4y ago
        Cool, then that spec is more useful than the one I was replying about.
- int_19h 4y ago
  And also data query & transformation languages like XSLT and XQuery that are designed around its data model.
  - sgc 4y ago
    Exactly. Xpath is great. Also, being able to have as many types of closing tags as you want to define, makes it much easier to visually parse what is going on in a complex data structure. That alone has a ton of value. I am still struggling for the right mix of highlighters and tools to work in various formats/languages, due to the opacity of closing structures like }]}]];. Now, there is a trade off in more complex paths to interoperability with Uncle Joe and his DTD. It is still easier than trying to parse some convoluted json coming from yet another api that the dev team never dogfed a day in their life - because you can jump levels so precisely in xpath due to those verbose types and attributes. So as to XML verbosity at least, which for many appears to be the main complaint, for me it is worth it when done right.
    - tokinonagare 4y ago
      I agree. User mcswell mentioned in another comment JSON config file, and I always fell somewhat uneasy with them (same but worse with YAML), while the redundancy in XML make it nicer to work with in my opinion. I'm very glad .NET Core switched back to XML-based MSBuild format instead of sticking with their new project.json stuff.
lucideer 4y ago
The popularity of the target isn't as really relevant here as the capability of the target. XML supports annotated trees (attributes + child nodes) whereas most popular modern interchange formats only support one of those dimensions (child nodes). Some of them do support types that xml lacks (integers, null, etc.) but these can be annotated in xml so the lack isn't critical. Ultimately what all that means is that all e.g. json documents can be represented losslessly in xml, whereas the reverse is not true without explicit external schema. Which means targeting XML covers other less capable interchange formats implicitly.

zapperdulchen 4y ago

There are XML workflows in technical documentation outside of software development where something like this could be of interest.

gavinray 4y ago

The fact that it's XML is not super relevant -- what you're working with in code is a tree structure that may as well be JSON or YAML This is essentially a way to write grammars for things and get the ability to parse them as trees in a common format that is interchangeable with things like JSON. I honestly don't see much of a difference between this, and something like a PEG grammar where you do this: let parsed = peg.parse(input, grammar) let xml = json2xml(parsed)

tokinonagare 4y ago

XML still has few advantages over JSON: comments, namespaces, a canonical form and slightly better extensibility.

tartoran 4y ago
At the expense of excessive verbosity. I used xml and still do to this day and it is one of my least favorite formats to read and edit.
mpyne 4y ago
JSON either has those (namespaces, extensibility) or the advantage is slight at best (comments, canonical form). There is a real advantage of XML over JSON not mentioned though, which is its usefulness in annotating computer-readable data into an otherwise human-editable document. There's not a lot of these cases, and where they're at you're probably still better off using AsciiDoc, Markdown or even HTML instead, but those use cases are out there and JSON is awful for those.
- mcswell 4y ago
  "the advantage is slight at best (comments...)" I suppose that's true if the data is generated by machine and consumed by machine, and never edited or looked at by humans. But JSON seems to be used in a lot of datasets that humans do touch, like config files that you can edit. Visual Studio Code is one such user, and I've had to edit my own VSC config files. And I use comments, because http://catb.org/~esr/writings/unix-koans/prodigy.html http://catb.org/~esr/writings/unix-koans/prodigy.html. Fortunately, VSC allows comments between a // and a following newline.
  - mpyne 4y ago
    > Fortunately, VSC allows comments between a // and a following newline. Yes, that's my point. If a human is required to look at the JSON it's not hard to find a parser that permits comments. So of course it would be supported if it was actually needed. Even without that though, you can do something like the trick I used in a JSON-based format: { "__comment": "For help with this file, go to http://wiki.example.com/ http://wiki.example.com/...", ... "foo": "..." } That does have the problem that your programs processing the JSON need to strip out keys with that name if it would interfere with the program. So it's probably easier just to add the line of code in your parser saying to permit comments. Meanwhile, XML comments have issues of their own, as you have to be familiar with SGML rules on how -- are handled to safely use or edit XML comments. So while they are nice to have it's not as if they have no nuance either.
- argomo 4y ago
  I'd add that another advantage of XML is that you get a powerful set of tools that are readily accessible across all "working" programming languages, often provided by first party libraries. Plus a lot of developers (and text editors) know the basic syntax. Granted, JSON has achieved this same level of universality, but everything else (excepting perhaps CSV files) either suffers from obscurity or from weak/ambiguous/competing specifications. The dream of semantically rich documents that XML provides (like, say, being able to cleanly interweave MathML, SVG, and XHTML in one document) is unmatched. I think we'd see a lot more XML usage if it hasn't been over-promised, over-delivered (WS-*), and over-used (enterprise Java). If XML had stuck to its lane (making a schema language like RelaxNG instead of XmlSchema, for one thing) it wouldn't have left such a bad taste in so many people's mouths.
Dylan16807 4y ago
Surely you could lay out a canonical form for JSON in like five minutes? Oh, here: https://www.rfc-editor.org/rfc/rfc8785 https://www.rfc-editor.org/rfc/rfc8785 No duplicates, no whitespace, sort the keys, copy number serialization from javascript, a couple other little details.
- tokinonagare 4y ago
  > Published:June 2020 This only two years old while JSON is in common usage for more than a decade... Without a spec there's dozen way to achieve it, for example by sorting keys using UTF-8 instead of UTF-16 values like done in this document, and the slightest difference would break things when used with crypto.
  - Dylan16807 4y ago
    If you're doing something cryptographic you need a spec for that anyway, so the extra work to specifying something like json sort order doesn't seem like it's a major factor to me.
    - tokinonagare 4y ago
      There's a spec for that already for XML: Signed XML. And the tooling that supports it, for instance on the .NET platform. So no need to create yet another spec and tools.
      - Dylan16807 4y ago
        Cool, then that spec is more useful than the one I was replying about.
int_19h 4y ago
And also data query & transformation languages like XSLT and XQuery that are designed around its data model.
- sgc 4y ago
  Exactly. Xpath is great. Also, being able to have as many types of closing tags as you want to define, makes it much easier to visually parse what is going on in a complex data structure. That alone has a ton of value. I am still struggling for the right mix of highlighters and tools to work in various formats/languages, due to the opacity of closing structures like }]}]];. Now, there is a trade off in more complex paths to interoperability with Uncle Joe and his DTD. It is still easier than trying to parse some convoluted json coming from yet another api that the dev team never dogfed a day in their life - because you can jump levels so precisely in xpath due to those verbose types and attributes. So as to XML verbosity at least, which for many appears to be the main complaint, for me it is worth it when done right.
  - tokinonagare 4y ago
    I agree. User mcswell mentioned in another comment JSON config file, and I always fell somewhat uneasy with them (same but worse with YAML), while the redundancy in XML make it nicer to work with in my opinion. I'm very glad .NET Core switched back to XML-based MSBuild format instead of sticking with their new project.json stuff.

lucideer 4y ago

The popularity of the target isn't as really relevant here as the capability of the target. XML supports annotated trees (attributes + child nodes) whereas most popular modern interchange formats only support one of those dimensions (child nodes). Some of them do support types that xml lacks (integers, null, etc.) but these can be annotated in xml so the lack isn't critical. Ultimately what all that means is that all e.g. json documents can be represented losslessly in xml, whereas the reverse is not true without explicit external schema. Which means targeting XML covers other less capable interchange formats implicitly.